unity-idm-discuss — Unity discussion and support

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!

ok my auth enumberation is working and already authenticating :-)))

i have another suggestion to make:

for installing plugins/additions via package-management it might be
beneficial to change the way the start-script calculates the classpath.

instead of

CP=.$(find "$LIB" -name '*.jar' -exec printf ":{}" \;)

use

CP=.$(find "$LIB" -type d -exec printf ":{}/*" \;)

this will shorten the commandline considerably and still include jar files
from subdirs.

cheers,

--
terefang





​

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 26.01.2015 o 23:35, Terefang Verigorn pisze:
> hi!
>
> seams that i have to revisit the BindingAuthn contract game, because
> some call traffic causes authentication errors.
>
>
> ah, some thoughts that have come up during consuming the unity code:
>
> * dont you intend to move the "public AuthenticationResult
> getAuthenticationResult();" method to the BindingAuthn interface, since
> every other derived interface defines (and needs) it anyway?

No, not every. In some situations the retrieval of AuthenticationResult 
is more complicated, e.g. async. See Vaadin authn (for the web UI).


> * as far a i have understood is that all "*Management" interfaces need
> some authorization to check.
>
> wouldnt it be logical to implement the actual functionality in a
> "*Helper" and let the "*Management" impl check for security and then
> delegate to the "*Helper".
>
> so server code may choose if they are doing administrative work, hence
> using "*Helper" beans directly
> or are subject to authorization, hence using "*Management" beans.

This is implemented in a cleaner way.
To have a manager which doesn't authorize, simply inject it with 
@Qualifier("insecure").

*Management is in general business logic including authZ. Helpers are 
helpers - with code shared between different managers. In couple of 
cases the authZ is more tightly bound to the logic so separating this is 
not that easy (e.g. if you have higher capabilities you will get more 
complete results).


> * wouldnt it make sense to have a "public static AuthenticatorImpl
> create(IdentityResolver idRes, AuthenticatorsRegistry authReg,
> AuthenticatorInstance instDescr);" in class AuthenticatorImpl ?
>
> so you can keep create code in one place and not all over.
>

Currently this 'all over' == AuthenticatorLoader. So the answer is 
rather not, as direct use of such method would anyway call for a helper 
bean which will have both bean dependencies injected - otherwise you 
have to inject 2 instead of 1;-) Yup, minimal difference.

BTW your approach would require more args (sql session to be able to 
join the running transaction) and more versions of create.


> * your code refers to a LICENSE.txt but neither the rpm nor the git-repo
> contain one.
>
> i have read on the webpage that unity-idm is licensed under permissive bsd,
> yet there are several (http://en.wikipedia.org/wiki/BSD_licenses)
>
> unless there a definitive LICENSE.txt i can refer to, i cant publish my
> code (open source it)
> under my preferred Apache License (http://choosealicense.com/licenses/)

Yes, it is BSD, and LICENSE.txt should be also in distribution. Will be 
fixed, thanks for the remainder.

Best,
Krzysztof

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!

seams that i have to revisit the BindingAuthn contract game, because some
call traffic causes authentication errors.


ah, some thoughts that have come up during consuming the unity code:

* dont you intend to move the "public AuthenticationResult
getAuthenticationResult();" method to the BindingAuthn interface, since
every other derived interface defines (and needs) it anyway?

* as far a i have understood is that all "*Management" interfaces need some
authorization to check.

wouldnt it be logical to implement the actual functionality in a "*Helper"
and let the "*Management" impl check for security and then delegate to the
"*Helper".

so server code may choose if they are doing administrative work, hence
using "*Helper" beans directly
or are subject to authorization, hence using "*Management" beans.

* wouldnt it make sense to have a "public static AuthenticatorImpl
create(IdentityResolver idRes, AuthenticatorsRegistry authReg,
AuthenticatorInstance instDescr);" in class AuthenticatorImpl ?

so you can keep create code in one place and not all over.

* your code refers to a LICENSE.txt but neither the rpm nor the git-repo
contain one.

i have read on the webpage that unity-idm is licensed under permissive bsd,
yet there are several (http://en.wikipedia.org/wiki/BSD_licenses)

unless there a definitive LICENSE.txt i can refer to, i cant publish my
code (open source it)
under my preferred Apache License (http://choosealicense.com/licenses/)



cheers,
--
terefang

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 23.01.2015 o 14:08, Terefang Verigorn pisze:
> hi!
>
> now i am really stimped, the code in AuthenticatorImpl does not make
> sense to me.

Unfortunately for 1.4.0 code (I've forgot about this) there is no easy 
solution - you need to code the whole authenticator creation logic. What 
is hard as you noticed. Fortunately in 1.5.0 (expected this week) you 
will have additional internal API which is supporting a new sandbox 
authN feature. This should help you:

i-face:

pl.edu.icm.unity.server.api.internal.AuthenticatorsManagement

with:

/**
  * Resolves binding specific authenticator authN implementations for a 
given
  * list of {@link AuthenticatorSet}.
  * @param authnList
  * @return
  * @throws EngineException
  */
List<Map<String, BindingAuthn>> 
getAuthenticatorUIs(List<AuthenticatorSet> authnList) throws 
EngineException;


BTW: internally you have two kinds of objects related to authenticatrs 
as one is intended for external users where details of an authenticator 
should be presented and internal objects which are supposed to work. 
Also the local verificators are configured, but implicitely - they rely 
on associated local credential's implementation, there is no need to 
introduce another configuration layer.

HTH,
Krzysztof

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!

now i am really stimped, the code in AuthenticatorImpl does not make sense
to me.

i use the following code accordung to the javadoc of the interface
---
for(AuthenticatorInstance authn : authnList)
{
AuthenticatorImpl authenticator = null;
if(!authn.getTypeDescription().isLocal() ||
authn.getLocalCredentialName()==null)
{
// remote auth
authenticator = new AuthenticatorImpl(
identityResolver,
 authenticatorsRegistry,
authn.getId(),
authn
);
}
else
{
// local auth
authenticator = new AuthenticatorImpl(
identityResolver,
authenticatorsRegistry,
authn.getId(),
authn,
authn.getVerificatorJsonConfiguration()
);
}
...
}
---

yet AuthenticatorImpl does this:
---
        public void updateConfiguration(String rConfiguration, String
vConfiguration, String localCredential)
        {
                if (rConfiguration == null)
                        rConfiguration = "";
                retrieval.setSerializedConfiguration(rConfiguration);

instanceDescription.setRetrievalJsonConfiguration(rConfiguration);
                verificator.setSerializedConfiguration(vConfiguration);
                if (!(verificator instanceof LocalCredentialVerificator))
                {

instanceDescription.setVerificatorJsonConfiguration(vConfiguration);
                } else
                {
--->>>
 instanceDescription.setVerificatorJsonConfiguration(null);

((LocalCredentialVerificator)verificator).setCredentialName(localCredential);

instanceDescription.setLocalCredentialName(localCredential);
                }
        }
---

why is the instance-description's config different than the verifiers ?

why does a local verifier have no config ? for a configurable multi-factor
authentication you might want one !


yours,

--
terefang



​

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!

(2) i would rather not reimplement a core function of unity.

(1) i will give it a shot

cheers,

--
terefang

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 23.01.2015 o 01:44, Terefang Verigorn pisze:
> (9) public Collection<String> authenticateUser(String userName, String
> password);
> (10) public Collection<String> authenticateUser(String userName, String
> password, String context);
> ---
> will return the list of principal names if authenticated(9) or only if
> user is assigned to context(10) else return null.
>
> in unity this means to use some credentialverifier
>
>         If you want to retrieve the authenticators configured for your
>         endpoint you can get them with getAuthenticators() method
>         inherited from AbstractEndpoint base class. Returns list of
>         authenticator sets with mirroring what you have configured in
>         endpoint's config in unityServer.conf. From the endpoint's
>         description you can retrieve the bare names of authenticators.
>
>
> the endpoints authenticator cannot be used, since it is only configured
> for (service) users (with the right) supposed to make calls to the endpoint.
>
> regular (real-life) users are not authorized to make calls to the
> endpoints, but need to be authenticated via the
> 'authenticateUser' method.
> * what i need is a way to enumberate all configured authenticaters (not
> only those of the endpoint).
>
> * make a guess which authenticators credentialverifier to use and call
> it -- i could either:
>
> configure the authenticators name in the endpoints private config
> OR
> use a global attribute on the entity to decide which authenticator to use
> (can use a input profile to map the proper attribute during ldap-auth)
>
>
> no i am not having only "one" ldap based authenticator,
> but around 10 of differing ads/openldap/sun/oracle/ibm (prod/qa/test).
>
> see my dilemma?

OK, now much more clear. So what you need here is to get 
CredentialVerificators which implement PasswordExchange as this is the 
only credential you want to verify.

CredentialVerificator is a part of Authenticator (together with 
retrieval which you don't need).

So now you have two ways to proceed:
1) Either use AuthenticationManagement to retrieve authenticators and 
use them. To get the expected functionality you will have to implement a 
trivial (noop in fact) retrieval (supporting some pseudo binding) that 
will directly expose the underlying verificator to your code. Then you 
can use it. Such authenticators won't work with any real endpoint but 
this shouldn't be a problem.

2) Or check the AuthenticationManagementImpl nad AuthenticatorImpl 
classes and reimplement their part that are responsible for creating 
CredentialVerificators. Create them in your code and that's all.

In both cases you need some configuration as you wrote to know which 
authenticators/verificators should be used. In (1) it can be probably 
simplified: you can use all authenticators supporting your pseudo binding.

Cheers,
Krzysztof

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!

ok some explaination, i will try to do this also for unity context

---
(1) public boolean userExists(String userName);
(2) public boolean userExists(String userName, String context);
---
will return true if users exists(1) or exists in context(2)

in unity this means either implicit context (1 == "/") or assigned to group
context (2 for example "/A/B/C")


---
(3) public Collection<String> resolveGroups(String userName);
(4) public Collection<String> resolveGroups(String userName, String
context);
---
will return the groups the user is assigned to(3) or filtered by context(4)

in unity this means either return all assigned groups of user(3) or
filtered with context used as prefix (4)

example: context="/" will return all groups of user
example: context="/A" will return [/A/B/C, /A/B, /A] of a user assigned to
/A/B/C and /D/E/F


---
(5) public Collection<String> resolveRoles(String userName);
(6) public Collection<String> resolveRoles(String userName, String context);
---
will return the roles the user is assigned to globally(5) or in context(6)

in unity this means to map certain defined attributes to the return list

how this should be done is TBD, but i currently have the following ideas:

* map each attribute with key starting with "role:"
string =
"${key}=${attr[key]}".substring(5).toUppercase().replaceAll("[^A-Z0-9]+","_")

* use a configured unity output profile to map attributes to role names
(need research).

* use a configured groovy-script (bsf or jsr223) to map attributes to role
names (already have knowledge).


---
(7) public Map<String,String> resolveAttributes(String userName);
(8) public Map<String,String> resolveAttributes(String userName, String
context);
---
will return the defined attributes of a user globally(7) or in context(8)

in unity this means either implicit context (attributes in "/") or group
context (attributes from for example "/A/B")

optionally, i would use a configured groovy-script (bsf or jsr223) to
translate/map attributes


---
(9) public Collection<String> authenticateUser(String userName, String
password);
(10) public Collection<String> authenticateUser(String userName, String
password, String context);
---
will return the list of principal names if authenticated(9) or only if user
is assigned to context(10) else return null.

in unity this means to use some credentialverifier

If you want to retrieve the authenticators configured for your endpoint you
>> can get them with getAuthenticators() method inherited from
>> AbstractEndpoint base class. Returns list of authenticator sets with
>> mirroring what you have configured in endpoint's config in
>> unityServer.conf. From the endpoint's description you can retrieve the bare
>> names of authenticators.
>
>
the endpoints authenticator cannot be used, since it is only configured for
(service) users (with the right) supposed to make calls to the endpoint.

regular (real-life) users are not authorized to make calls to the
endpoints, but need to be authenticated via the
'authenticateUser' method.

* what i need is a way to enumberate all configured authenticaters (not
only those of the endpoint).

* make a guess which authenticators credentialverifier to use and call it
-- i could either:

configure the authenticators name in the endpoints private config
OR
use a global attribute on the entity to decide which authenticator to use
(can use a input profile to map the proper attribute during ldap-auth)


no i am not having only "one" ldap based authenticator,
but around 10 of differing ads/openldap/sun/oracle/ibm (prod/qa/test).

see my dilemma?

cheers,
--
terefang

-- 
Schonmal davon gehoert, dass nicht jeder linux user gleich ein
programmierer ist, der alles, was er selber braucht, auch selber
programmiert, installiert, patched, hacked oder portiert?

Urks?  Das ist doch nur eine Legende.....

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 22.01.2015 o 16:27, Terefang Verigorn pisze:
>     Yes, this is quite a lot of work, and rather difficult - you have to
>     understand in details what happens, what is the order of invocation etc.
>
>
> ok, all that works now :-)

wow, that was quick. Congrats!

> public Collection<String> authenticateUser(String userName, String
> password);
> public Collection<String> authenticateUser(String userName, String
> password, String context);
[CUT]
> but i have no idea how i can implement "authenticateUser" -- surely i
> cannot use the bindauthn
> of the endpoint since they are only for the webservice authn/z.
>
> how would i resolve an authenticator-name configured in the endpoints
> private config ?
>
> how would i resolve any of the preconfigured authenticators
> (pwdWeb,ldapWeb,...) ?
> from spring appcontext?

First, can you please explain what the methods are supposed to return?
If you want to retrieve the authenticators configured for your endpoint 
you can get them with getAuthenticators() method inherited from 
AbstractEndpoint base class. Returns list of authenticator sets with 
mirroring what you have configured in endpoint's config in 
unityServer.conf. From the endpoint's description you can retrieve the 
bare names of authenticators.

However note that you will have to make some tricks, as you don't need 
an authenticator (binding specific) but only its one part: the 
credential verificator, as you want to simply verify a credential that 
you have at hand. You can try to expose it from your binding specific 
authenticator (so your retrieval).

Cheers,
Krzysztof

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!


> All examples will refer to the unity-server-rest module which is the most
> similar.
>
> 1) You need to define a contract (interface) for authenticators to
> retrieve credentials from your binding. As in your case it is low level
> then your retrievals should be servlet filters. Example: CXFAuthentication
> (which uses interceptros)
> 2) You will have to implement a credential retrieval (implementing a
> contract from (1)) for each credential which you are going to use with this
> binding. Retrievals are responsible for getting a credential in a transport
> specific way and then use a provided verificator to check it. Examples:
> HttpBasicRetrieval*
> 3) You will need to code a class that will be responsible for collecting a
> complete authentication result, by retrieving authn results from all
> authenticators (guys from (2)) and feeding it to generic Unity code to get
> a composite decision. It will be another servelt filter in your case. See
> AuthenticationInterceptor.
> 4) You will need a code that will install all authenticators (of course
> Unity ensures that only compatible authenticators can be used used) on an
> endpoint (i.e. it will install the filters, including the final one from
> (3)). Example: RESTEndpoint#installAuthnInterceptors()
>
> Yes, this is quite a lot of work, and rather difficult - you have to
> understand in details what happens, what is the order of invocation etc.
>

ok, all that works now :-)

although i have implemented it according to your list, i think a can merge
the two filters into one.

to get the most out of it i authenticate as a special created "websvc" to
get a maximum of visibility.

i would like to implement the follow api:

---
public interface JsonRpcInterface
{
public boolean userExists(String userName);
public boolean userExists(String userName, String context);
 public Collection<String> authenticateUser(String userName, String
password);
public Collection<String> authenticateUser(String userName, String
password, String context);

public Collection<String> resolveGroups(String userName);
public Collection<String> resolveGroups(String userName, String context);

public Collection<String> resolveRoles(String userName);
public Collection<String> resolveRoles(String userName, String context);

public Map<String,String> resolveAttributes(String userName);
public Map<String,String> resolveAttributes(String userName, String
context);
}
---

userExists/resolveGroups/resolveAttributes already work as expected

resolveRoles will be implemented with a translation profile config later.

but i have no idea how i can implement "authenticateUser" -- surely i
cannot use the bindauthn
of the endpoint since they are only for the webservice authn/z.

how would i resolve an authenticator-name configured in the endpoints
private config ?

how would i resolve any of the preconfigured authenticators
(pwdWeb,ldapWeb,...) ?
from spring appcontext?


cheers,

--
terefang

-- 
Schonmal davon gehoert, dass nicht jeder linux user gleich ein
programmierer ist, der alles, was er selber braucht, auch selber
programmiert, installiert, patched, hacked oder portiert?

Urks?  Das ist doch nur eine Legende.....

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 22.01.2015 o 10:13, Terefang Verigorn pisze:
> hi!
>
> i think that other 3rd parties might also like to go the non jax-rs route.
>
> we decided to use json-rpc with only the basic java objects
> (Collection, Map, String, Integer, Boolean, Long, Float, Double)
> for maximum interoperability due to language issues (perl, python, java,
> dotnet)
> (http://json-rpc.org/wiki/specification)
>
> for our java environment we chose jsonrpc4j, since it can be used
> over almost any transport (stream) and and can use interface proxies.
> (https://github.com/briandilley/jsonrpc4j#client)
>
> unit testing the rpc calls is trivial.
> (i use RESTClient for directly calling the endpoint for verification)

Well, I agree that JSON-RPC is both easy and portable. However, any 
other JSON based API (including RESTful APIs) is portable and even if 
you have JAX-RS based server side implementation you can use any 
technology to access the service. The real difference is around 'easy'. 
With the 'manually' created REST API you have to code more as you design 
how you use the low level (HTTP) protocol: what JSON objects are 
exchanged and what are the paths&params to send/get them. With JSON RPC 
you get this all for free.

Now, the question is how you build this API. If you simply mirror the 
internal Unity API then you will have troubles when it will come to 
upgrade the server: Unity internal API and its params is subject to 
change. If you on another hand designed your own remote API and expose 
it via JSON-RPC then you will have more control and probably will be 
able to mask underlying Unity API changes. However also similar amount 
of work as in the RESTful API case so no much gain...

OK, I don't know your use case so the above it is purely theoretical:)


> ok now making it work ...

So how to implement a new binding?

All examples will refer to the unity-server-rest module which is the 
most similar.

1) You need to define a contract (interface) for authenticators to 
retrieve credentials from your binding. As in your case it is low level 
then your retrievals should be servlet filters. Example: 
CXFAuthentication (which uses interceptros)
2) You will have to implement a credential retrieval (implementing a 
contract from (1)) for each credential which you are going to use with 
this binding. Retrievals are responsible for getting a credential in a 
transport specific way and then use a provided verificator to check it. 
Examples: HttpBasicRetrieval*
3) You will need to code a class that will be responsible for collecting 
a complete authentication result, by retrieving authn results from all 
authenticators (guys from (2)) and feeding it to generic Unity code to 
get a composite decision. It will be another servelt filter in your 
case. See AuthenticationInterceptor.
4) You will need a code that will install all authenticators (of course 
Unity ensures that only compatible authenticators can be used used) on 
an endpoint (i.e. it will install the filters, including the final one 
from (3)). Example: RESTEndpoint#installAuthnInterceptors()

Yes, this is quite a lot of work, and rather difficult - you have to 
understand in details what happens, what is the order of invocation etc.

Good luck,
Krzysztof

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hi!

i think that other 3rd parties might also like to go the non jax-rs route.

we decided to use json-rpc with only the basic java objects
(Collection, Map, String, Integer, Boolean, Long, Float, Double)
for maximum interoperability due to language issues (perl, python, java,
dotnet)
(http://json-rpc.org/wiki/specification)

for our java environment we chose jsonrpc4j, since it can be used
over almost any transport (stream) and and can use interface proxies.
(https://github.com/briandilley/jsonrpc4j#client)

unit testing the rpc calls is trivial.
(i use RESTClient for directly calling the endpoint for verification)

ok now making it work ...

i already know that i need an authentication filter -- my current code
looks like this:
---
@Override
public ServletContextHandler getServletContextHandler()
{
if (context != null)
return context;
  context = new ServletContextHandler(ServletContextHandler.SESSIONS);
context.setContextPath(description.getContextAddress());

// authnFilter = ...
 // context.addFilter(new FilterHolder(authnFilter), "/*",
EnumSet.of(DispatcherType.REQUEST));
 JsonRpcServlet theServlet = new JsonRpcServlet();
theServlet.setAttributesManagement(attributesMan);
theServlet.setGroupsManagement(groupsMan);
theServlet.setIdentitiesManagement(identitiesMan);
theServlet.setSessionManagement(sessionMan);

context.addServlet(createServletHolder(theServlet),
this.getEndpointDescription().getContextAddress()+"/json-rpc");
 return context;
}

protected ServletHolder createServletHolder(Servlet servlet)
{
ServletHolder holder = new ServletHolder(servlet);

holder.setInitParameter("closeIdleSessions", "true");
holder.setInitParameter("session-timeout", "3600");

return holder;
}
---

can you point me in the right direction ?

regards,

--
terefang
​

Re: [Unity-idm-discuss] custom servlet endpoint authentication

[Krzysztof B. <go...@ic...>]

Hi Terefang,

W dniu 21.01.2015 o 19:26, Terefang Verigorn pisze:
> i do need a rpc api on top of unity so i implemented an endpoint
> (+factory+servlet)

I guess that you want to have quick and easy implementation exposing the 
full Unity API remotely. However have you considered doing it different 
(and maybe looking bit harder at the first sight) way, i.e. extending 
the current REST admin endpoint? Adding couple of additional operations 
won't be much work. Such approach has the advantage of a cleaner API and 
proper control over on-the-wire contents. It is also somewhere on the 
horizon for the official Unity distro (and also all contributions are 
welcomed).


> and hooked i up like this in unityServer.conf:
>
> ----
> unityServer.core.endpoints.11.endpointType=JsonRpc
> unityServer.core.endpoints.11.endpointConfigurationFile=/etc/unity-idm/endpoints/jsonrpc.properties
> unityServer.core.endpoints.11.contextPath=/rpc
> unityServer.core.endpoints.11.endpointName=UNITY json-rpc endpoint
> unityServer.core.endpoints.11.endpointRealm=defaultRealm
> unityServer.core.endpoints.11.endpointAuthenticators=pwdRest
> ----
>
> i can reach the endpoint servlet, but any call to an unity api
> (IdentitiesManagement, GroupsManagement, AttributesManagement) will
> result in the following Exception:
>
> ----
> 2015-01-21 17:47:25,238 [qtp37986510-36] WARN
>   terefang.unity.contrib.jsonrpc.JsonRpcServlet  - The current call has
> no invocation context set
[CUT]
> it seams that the configured authentication methods do not get processed
> and hence the api calls are unauthorized

So AFAIU without looking at your code you try not only to create a new 
Unity endpoint, but also a new endpoint binding, which can be called 
"plain servlet" in your case. Your configuration is using restful 
authenticator but I'm afraid your endpoint is not restful (JAX-RS based)?

This is much harder then creating a new endpoint for existing binding 
(which are Vaadin, Web Service with CXF and RESTful with JAX-RS). When 
going into this direction you have to implement the whole authentication 
logic for this binding, something you get for free when reusing an 
existing endpoint type.

If you are really interested in this direction I can give you some 
hints, of course.

Take care,
Krzysztof

[Unity-idm-discuss] custom servlet endpoint authentication

[Terefang V. <ter...@gm...>]

hello

first of all thanks for this wonderful software.

i do need a rpc api on top of unity so i implemented an endpoint
(+factory+servlet)
and hooked i up like this in unityServer.conf:

----
unityServer.core.endpoints.11.endpointType=JsonRpc
unityServer.core.endpoints.11.endpointConfigurationFile=/etc/unity-idm/endpoints/jsonrpc.properties
unityServer.core.endpoints.11.contextPath=/rpc
unityServer.core.endpoints.11.endpointName=UNITY json-rpc endpoint
unityServer.core.endpoints.11.endpointRealm=defaultRealm
unityServer.core.endpoints.11.endpointAuthenticators=pwdRest
----

i can reach the endpoint servlet, but any call to an unity api
(IdentitiesManagement, GroupsManagement, AttributesManagement) will result
in the following Exception:

----
2015-01-21 17:47:25,238 [qtp37986510-36] WARN
 terefang.unity.contrib.jsonrpc.JsonRpcServlet  - The current call has no
invocation context set
pl.edu.icm.unity.exceptions.InternalException: The current call has no
invocation context set
at
pl.edu.icm.unity.server.authn.InvocationContext.getCurrent(InvocationContext.java:57)
at
pl.edu.icm.unity.engine.events.EventDecoratingHandler.invoke(EventDecoratingHandler.java:39)
at com.sun.proxy.$Proxy19.getEntity(Unknown Source)
at
terefang.unity.contrib.jsonrpc.JsonRpcServlet.userExists(JsonRpcServlet.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.googlecode.jsonrpc4j.JsonRpcServer.invoke(JsonRpcServer.java:513)
at
com.googlecode.jsonrpc4j.JsonRpcServer.handleObject(JsonRpcServer.java:384)
at com.googlecode.jsonrpc4j.JsonRpcServer.handleNode(JsonRpcServer.java:293)
at com.googlecode.jsonrpc4j.JsonRpcServer.handle(JsonRpcServer.java:230)
at com.googlecode.jsonrpc4j.JsonRpcServer.handle(JsonRpcServer.java:207)
at
terefang.unity.contrib.jsonrpc.JsonRpcServlet.doPost(JsonRpcServlet.java:67)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:503)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:229)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:429)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at
org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:317)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SslConnection.handle(SslConnection.java:196)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
----

it seams that the configured authentication methods do not get processed
and hence the api calls are unauthorized

i have looked into the other endpoints (Vaadim, CXF, Rest) but i do not
understand how they authenticate via http-basic.

please help.

yours,

--
terefang

Re: [Unity-idm-discuss] Any plans for a PAM usable endpoint?

[Krzysztof B. <go...@ic...>]

Hi Jeroen,

W dniu 20.01.2015 o 10:52, Jeroen Roodhart pisze:
> Hi Krzysztof,
>
> Thank you for your clear answer.
>
> On 20/01/15 10:27, Krzysztof Benedyczak wrote:
>> That said such implementation is considered but pretty low on
>> priorities list. This is because of minimal usefulness and very big
>> effort to implement it.
>
> Well, I agree that it would be a big effort, though I think it would
> be _very_ useful. At the moment there seems to be no way whatsoever to
> tie into OAUTH or other such mechanisms on the system level. Having
> such a possibility would open up a plethora of possibilities to allow
> collaboration between researchers through sharing all kinds of
> resources (from compute facilities (not being "cloud") to scientific
> measuring equipment).

To clarify bit more. I fully agree that a feature to authenticate Linux 
users with basically anything would be great. But my point was that in 
many (most? i.e. OAuth & typical SAML) cases it is close to impossible. 
Developing an automated web parser which will login on user's behalf 
using an arbitrary login fields on an arbitrary login page - which each 
and every IdP can have different and usually does have different - is 
fairly unrealistic. We can do something for some well known providers as 
Google or FB.

My statement that "this is a lot of work" was related merely to the LDAP 
endpoint in Unity which is needed to create PAM<->Unity link, but is not 
sufficient as it won't translate non-interactive protocol (LDAP) to any 
interactive web-browser based protocol (OAuth/SAML SSO).

Also simulated&automated web-browser approach brings legal issues as the 
whole solution would be a hack, killing the principles of OAuth/SAML 
protocols where the password is not exposed to intermediaries and where 
a user is directly instructing her IdP to release the information to a 
particular requester.

Simple example: if the IdP asks the user (after login) whether she 
accepts some new, updated terms and conditions, Unity should click "yes" 
for the user? Or maybe not?

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Any plans for a PAM usable endpoint?

[Jeroen R. <j.r...@uv...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Krzysztof,

Thank you for your clear answer.

On 20/01/15 10:27, Krzysztof Benedyczak wrote:
> That said such implementation is considered but pretty low on
> priorities list. This is because of minimal usefulness and very big
> effort to implement it.

Well, I agree that it would be a big effort, though I think it would
be _very_ useful. At the moment there seems to be no way whatsoever to
tie into OAUTH or other such mechanisms on the system level. Having
such a possibility would open up a plethora of possibilities to allow
collaboration between researchers through sharing all kinds of
resources (from compute facilities (not being "cloud") to scientific
measuring equipment).

With kind regards,

Jeroen
- -- 
_________________________________________________
Jeroen Roodhart			University of Amsterdam
Strategic IT Consultant		Science faculty
				Researcher's IT support
j.r...@uv...		fei...@uv...
Tel. 020 525 7203		Tel. 020 525 7202
- --
See http://www.uva.nl/profile/j.r.roodhart for openPGP public key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlS+JVoACgkQ37AP1zFtDU0q7QCcCAXXkWGPzsWhAGn5odrm8HC3
JGwAoIA4YSnQy/wSEpLsSPMbU3qwoROj
=Ow46
-----END PGP SIGNATURE-----

Re: [Unity-idm-discuss] Any plans for a PAM usable endpoint?

[Krzysztof B. <go...@ic...>]

Dear Jeroen,

W dniu 19.01.2015 o 20:38, Jeroen Roodhart pisze:
> Dear list,
>
> You probably get this asked a lot, but I'll try anyway :)
>
> We are considering Unity in hopes that it provides a way to tie many
> identity and authorisation providers in such a way that it can be used
> to provide system level (PAM) access to Linux/Unix servers (and
> services such as iRODS).
>
> Are you considering developing say a LDAP/AD endpoint for Unity?

Maybe not a lot, but you are right - such question was asked. And yes, I 
agree that LDAP endpoint is the best way to integrate Unity with PAM.

That said such implementation is considered but pretty low on priorities 
list. This is because of minimal usefulness and very big effort to 
implement it.

The root of all evil is that the most popular distributed authentication 
protocols - OAuth2/OIDC and SAML Web SSO - are web based by design. I.e. 
protocol spec assumes that a principal being authenticated uses web 
browser, dot. Yes, there is SAML ECP profile which would be suitable, 
also it is (I guess) possible to create non-browser login under OAuth 
umbrella, but the reality is that IdPs do not (widely) support anything 
like this.

All in all LDAP-endpoint in Unity would allow you to perform authN 
against credential stored in Unity or against another LDAP server. Not 
much I'm afraid. Another option is to simulate web-browser in Unity so 
it will login on user's behalf but such approach is extremely hard to 
maintain and limited as IdP login forms do differ a lot.


Best regards,
Krzysztof

[Unity-idm-discuss] Any plans for a PAM usable endpoint?

[Jeroen R. <j.r...@uv...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear list,

You probably get this asked a lot, but I'll try anyway :)

We are considering Unity in hopes that it provides a way to tie many
identity and authorisation providers in such a way that it can be used
to provide system level (PAM) access to Linux/Unix servers (and
services such as iRODS).

Are you considering developing say a LDAP/AD endpoint for Unity?

With kind regards,

Jeroen Roodhart
- -- 
_________________________________________________
Jeroen Roodhart			University of Amsterdam
Strategic IT Consultant		Science faculty
				Researcher's IT support
j.r...@uv...		fei...@uv...
Tel. 020 525 7203		Tel. 020 525 7202
- --
See http://www.uva.nl/profile/j.r.roodhart for openPGP public key
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlS9XTwACgkQ37AP1zFtDU3nOwCdG2G0+bJxIFjPLcpG1gVaAvd4
utoAoKhhqgmx5FDTgnXXmhUWQmOY6gH/
=lnqy
-----END PGP SIGNATURE-----

[Unity-idm-discuss] Release 1.4.0 available

[Krzysztof B. <go...@ic...>]

Dear All,

Finally the 1.4.0 release of Unity is available for download.
It is so far the biggest update, with exactly 200 commits, 47 solved 
tickets and several big features.

Big thanks to all our contributors, testers and auditors (in 
alphabetical order, people first): Bernd, Piotr, Rafał, Roman Krysiński, 
Shiraz, ICM, Wrocław Center For Networking and Supercomputing, ICM and 
PL-Grid guys!


The release highlights are:

* OAuth2 & OpenID Connect endpoint is now available, i.e. Unity can act 
as a standalone OAuth 2 Authorization Server with support for OpenID 
Connect specification. The current implementation is fully functional, 
however its configuration requires some manual work in Admin UI
(setting attributes, adding clients to groups) as there is no dedicated 
OAuth management UI. This will be improved in future.

* The SAML subsystem received all the most important missing features:
** Support for encryption (and decryption) of assertions.
** SAML IdP can be configured with SAML metadata in the similar way as 
it was already possible to configure SAMl authenticator. The trusted SPs 
are can be automatically extracted from the federation's metadata and 
updated at runtime.
** SAML Single Logout protocol is fully supported. This is a giant 
feature, as Unity can now logout all session participants: the upstream 
SAML IdP (if was used) and the SPs logged via Unity SAML IdP endpoint.
The logout can be initiated and performed via HTTP POST, Redirect and 
SOAP bindings, as well as by logging out from any of the Unity web UIs. 
As Single Logout may bring some problems level of its implementation is 
configurable. See the SAML Howto for details.

* LDAP authenticator was greatly enhanced:
** it is possible to use a predefined system user to obtain information 
about logged user
** it is possible to define custom, additional searches

* There is a new OAuth authenticator available, where Unity takes OAuth 
Resource Server role, checking provided OAuth Access Token against a 
configured 3rd party OAuth AS.

* Unity was subject to an extensive security audit. Implementation of 
audit recommendations hardened Unity's security.


Unfortunately one of the big planned features - translation profile 
wizard and debugger - is not included in this release due to one lately 
found issue. This great feature will be made available in the next release.

The full list of changes & updated documentation are available as always 
at http://www.unity-idm.eu

Best regards,
Krzysztof

Re: [Unity-idm-discuss] missing unity:identity:* attributes in v1.3.1

[Shiraz M. <a....@fz...>]

Hi Krzysztof,


Hard to say. I have a feeling that you had some problems with the upgrade.
Between 1.3.0 and 1.3.1 there were only few bugfixes, absolutely nothing more; the similar issue was with the tiket you've filled. Between 1.2.0 and 1.3.x there was a change in this field. Check the output translation profile chapter in the manual.

Yup, the translation profile helped.

Thanks,
Shiraz
 --
Ahmed Shiraz Memon
Federated Systems and Data
Jülich Supercomputing Centre (JSC)

Phone: +49 2461 61 6899
Fax:     +49 2461 61 6656


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Re: [Unity-idm-discuss] missing unity:identity:* attributes in v1.3.1

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 20.10.2014 o 12:49, Shiraz Memon pisze:
> Hi,
>
> I am currently testing v1.3.1. Surprisingly, after successful
> authentication, the assertion consumer service (the SP) fails to receive
> the unity:identity:* prefixed attributes (e.g.
> unity:identity:persistent) from the unity idp. That was not the case in
> v1.3.0, though. Do I need to configure anything inside unity's saml
> web-idp settings?

Hard to say. I have a feeling that you had some problems with the 
upgrade. Between 1.3.0 and 1.3.1 there were only few bugfixes, 
absolutely nothing more; the similar issue was with the tiket you've 
filled. Between 1.2.0 and 1.3.x there was a change in this field. Check 
the output translation profile chapter in the manual.

So I guess you have a default output profile installed, which is not 
exposing identities of the user in attributes. However it is easy to add 
such: the example in the documentation shows how to do this. You can 
name the reulting attribute in anyway you want and expose the identity 
types you are interested in.

Best regards,
Krzysztof

[Unity-idm-discuss] missing unity:identity:* attributes in v1.3.1

[Shiraz M. <a....@fz...>]

Hi,

I am currently testing v1.3.1. Surprisingly, after successful authentication, the assertion consumer service (the SP) fails to receive the unity:identity:* prefixed attributes (e.g. unity:identity:persistent) from the unity idp. That was not the case in v1.3.0, though. Do I need to configure anything inside unity's saml web-idp settings?

Thanks,
Shiraz
--
Ahmed Shiraz Memon
Federated Systems and Data
Jülich Supercomputing Centre (JSC)

Phone: +49 2461 61 6899
Fax:     +49 2461 61 6656


------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

Re: [Unity-idm-discuss] Unity - LDAP Integration

[Krzysztof B. <go...@ic...>]

Hi,

W dniu 21.08.2014 12:08, mahind pisze:
> Hello,
>
> I am using Unity version 1.3.1.
>
> The test user is registered in OpenLDAP.
>
> I am trying to get authentication from UNICORE commandline client (ucc)
> via Unity.
>
>  From ucc I am able to get authentication for users registered in Unity.
>
> With the help of documentation, I configured unityServer.log for
> authenticator and endpoint settings.
>
>     unityServer.core.authenticators.4.authenticatorName=ldapWeb
>     unityServer.core.authenticators.4.authenticatorType=ldap with
>     web-password
>     unityServer.core.authenticators.4.verificatorConfigurationFile=conf/authenticators/ldap.properties
>     unityServer.core.authenticators.4.retrievalConfigurationFile=conf/authenticators/passwordRetrieval.json
>
>     unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
>     unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
>     unityServer.core.endpoints.4.contextPath=/unicore-soapidp
>     unityServer.core.endpoints.4.endpointRealm=defaultRealm
>     unityServer.core.endpoints.4.endpointName=UNITY UNICORE SOAP SAML
>     service
>     unityServer.core.endpoints.4.endpointAuthenticators=pwdWS;ldapWeb
>
>
> Also updated conf/authenticators/ldap.properties
>
>     ldap.servers.1=xxx
>     ldap.ports.1=xxx
>
>     ldap.userDNTemplate=uid={USERNAME},ou=users,dc=tu-dresden,dc=de
>     ldap.attributes.1=uid
>     ldap.groupsBaseName=dc=tu-dresden,dc=de
>     ldap.groups.1.objectClass=groups
>     ldap.groups.1.memberAttribute=memberUid
>     ldap.groups.1.matchByMemberAttribute=cn
>     ldap.groups.1.nameAttribute=cn
>
>     ldap.translationProfile=ldapProfile
>
>
> When I try to connect, I get -
>
> **************************
> Starting UNITY Web Server
> **************************
> 2014-08-21 09:29:30,340 [main] INFO unity.server.config.JettyServerBase
> - Creating Jetty HTTP server, will listen on: https://xxx
> 2014-08-21 09:29:34,058 [main] INFO  unity.server.db.InitDB  - Database
> initialized, skipping creation
> 2014-08-21 09:29:39,679 [main] INFO unity.server.EngineInitialization  -
> Checking if all identity types are defined
> 2014-08-21 09:29:39,783 [main] INFO unity.server.EngineInitialization  -
> Checking if all system attribute types are defined
> 2014-08-21 09:29:40,268 [main] INFO unity.server.EngineInitialization  -
> Loading all configured credentials
> 2014-08-21 09:29:40,297 [main] INFO unity.server.EngineInitialization  -
> Loading all configured credential requirements
> 2014-08-21 09:29:40,388 [main] INFO unity.server.EngineInitialization  -
> Loading configured translation profiles
> 2014-08-21 09:29:40,389 [main] INFO unity.server.EngineInitialization  -
> Loading all configured authenticators
> 2014-08-21 09:29:40,418 [main] INFO unity.server.EngineInitialization  -
> Removing all persisted endpoints
> 2014-08-21 09:29:40,431 [main] INFO unity.server.EngineInitialization  -
> Removing all persisted realms
> 2014-08-21 09:29:40,464 [main] INFO unity.server.EngineInitialization  -
> Loading configured realms
> 2014-08-21 09:29:40,487 [main] INFO unity.server.EngineInitialization
> -  - defaultRealm:  [blockAfter 4, blockFor 30, rememberMe -1,
> maxInactive 3600
> 2014-08-21 09:29:40,500 [main] INFO unity.server.EngineInitialization
> -  - adminRealm:  [blockAfter 4, blockFor 30, rememberMe -1, maxInactive
> 1800
> 2014-08-21 09:29:40,500 [main] INFO unity.server.EngineInitialization  -
> Loading all configured endpoints
> 2014-08-21 09:29:40,729 [main] INFO unity.server.EngineInitialization
> -  - UNITY administration interface: WebAdminUI
> 2014-08-21 09:29:41,776 [main] INFO unity.server.EngineInitialization
> -  - UNITY SAML web authentication: SAMLWebIdP
> 2014-08-21 09:29:41,844 [main] INFO unity.server.EngineInitialization
> -  - UNITY UNICORE web authentication: SAMLUnicoreWebIdP
> 2014-08-21 09:29:41,891 [main] FATAL unity.server.EngineInitialization
> - Can't load endpoints which are configured
> pl.edu.icm.unity.exceptions.EngineException: Unable to deploy an
> endpoint: The authenticator of type web-vaadin7 is not supported by the
> binding. Supported are: [webservice-cxf2]
>          at
> pl.edu.icm.unity.engine.EndpointManagementImpl.deployInt(EndpointManagementImpl.java:132)
>          at
> pl.edu.icm.unity.engine.EndpointManagementImpl.deploy(EndpointManagementImpl.java:101)
>          at
> pl.edu.icm.unity.engine.internal.EngineInitialization.loadEndpointsFromConfiguration(EngineInitialization.java:631)
>          at
> pl.edu.icm.unity.engine.internal.EngineInitialization.initializeEndpoints(EngineInitialization.java:579)
>          at
> pl.edu.icm.unity.engine.internal.EngineInitialization.initializeDatabaseContents(EngineInitialization.java:282)
>          at
> pl.edu.icm.unity.engine.internal.EngineInitialization.start(EngineInitialization.java:181)
>          at
> org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)
>          at
> org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
>          at
> org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
>          at
> org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
>          at
> org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
>          at
> org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:773)
>          at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:485)
>          at
> pl.edu.icm.unity.server.UnityApplication.run(UnityApplication.java:50)
>          at
> pl.edu.icm.unity.server.UnityApplication.main(UnityApplication.java:58)
> Caused by: pl.edu.icm.unity.exceptions.WrongArgumentException: The
> authenticator of type web-vaadin7 is not supported by the binding.
> Supported are: [webservice-cxf2]
>          at
> pl.edu.icm.unity.engine.EndpointManagementImpl.verifyAuthenticators(EndpointManagementImpl.java:147)
>          at
> pl.edu.icm.unity.engine.EndpointManagementImpl.deployInt(EndpointManagementImpl.java:120)
>          ... 14 more
>
> Is there any mistake in configuration?

Yes, there is. As the error message says the authenticator is 
incompatible with the endpoint. The authenticator 'ldapWeb' can be used 
only for web endpoints as it is configured to retrieve user's password 
using the web form (see documentation of authenticators):

unityServer.core.authenticators.4.authenticatorType=ldap with web-password

It is not possible to use it with SOAP endpoint, used by UCC or URC. SO 
you need to define another authenticator (LDAP specific part can reuse 
the same configuration file), but the new authenticator must be of type:

ldap with cxf-httpbasic

This authenticator will work with the SOAP endpoint.

Best,
Krzysztof

[Unity-idm-discuss] Unity - LDAP Integration

[mahind <atu...@ma...>]

Hello,

I am using Unity version 1.3.1.

The test user is registered in OpenLDAP.

I am trying to get authentication from UNICORE commandline client (ucc) 
via Unity.

 From ucc I am able to get authentication for users registered in Unity.

With the help of documentation, I configured unityServer.log for 
authenticator and endpoint settings.

    unityServer.core.authenticators.4.authenticatorName=ldapWeb
    unityServer.core.authenticators.4.authenticatorType=ldap with
    web-password
    unityServer.core.authenticators.4.verificatorConfigurationFile=conf/authenticators/ldap.properties
    unityServer.core.authenticators.4.retrievalConfigurationFile=conf/authenticators/passwordRetrieval.json

    unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
    unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
    unityServer.core.endpoints.4.contextPath=/unicore-soapidp
    unityServer.core.endpoints.4.endpointRealm=defaultRealm
    unityServer.core.endpoints.4.endpointName=UNITY UNICORE SOAP SAML
    service
    unityServer.core.endpoints.4.endpointAuthenticators=pwdWS;ldapWeb


Also updated conf/authenticators/ldap.properties

    ldap.servers.1=xxx
    ldap.ports.1=xxx

    ldap.userDNTemplate=uid={USERNAME},ou=users,dc=tu-dresden,dc=de
    ldap.attributes.1=uid
    ldap.groupsBaseName=dc=tu-dresden,dc=de
    ldap.groups.1.objectClass=groups
    ldap.groups.1.memberAttribute=memberUid
    ldap.groups.1.matchByMemberAttribute=cn
    ldap.groups.1.nameAttribute=cn

    ldap.translationProfile=ldapProfile


When I try to connect, I get -

**************************
Starting UNITY Web Server
**************************
2014-08-21 09:29:30,340 [main] INFO unity.server.config.JettyServerBase  
- Creating Jetty HTTP server, will listen on: https://xxx
2014-08-21 09:29:34,058 [main] INFO  unity.server.db.InitDB  - Database 
initialized, skipping creation
2014-08-21 09:29:39,679 [main] INFO unity.server.EngineInitialization  - 
Checking if all identity types are defined
2014-08-21 09:29:39,783 [main] INFO unity.server.EngineInitialization  - 
Checking if all system attribute types are defined
2014-08-21 09:29:40,268 [main] INFO unity.server.EngineInitialization  - 
Loading all configured credentials
2014-08-21 09:29:40,297 [main] INFO unity.server.EngineInitialization  - 
Loading all configured credential requirements
2014-08-21 09:29:40,388 [main] INFO unity.server.EngineInitialization  - 
Loading configured translation profiles
2014-08-21 09:29:40,389 [main] INFO unity.server.EngineInitialization  - 
Loading all configured authenticators
2014-08-21 09:29:40,418 [main] INFO unity.server.EngineInitialization  - 
Removing all persisted endpoints
2014-08-21 09:29:40,431 [main] INFO unity.server.EngineInitialization  - 
Removing all persisted realms
2014-08-21 09:29:40,464 [main] INFO unity.server.EngineInitialization  - 
Loading configured realms
2014-08-21 09:29:40,487 [main] INFO unity.server.EngineInitialization  
-  - defaultRealm:  [blockAfter 4, blockFor 30, rememberMe -1, 
maxInactive 3600
2014-08-21 09:29:40,500 [main] INFO unity.server.EngineInitialization  
-  - adminRealm:  [blockAfter 4, blockFor 30, rememberMe -1, maxInactive 
1800
2014-08-21 09:29:40,500 [main] INFO unity.server.EngineInitialization  - 
Loading all configured endpoints
2014-08-21 09:29:40,729 [main] INFO unity.server.EngineInitialization  
-  - UNITY administration interface: WebAdminUI
2014-08-21 09:29:41,776 [main] INFO unity.server.EngineInitialization  
-  - UNITY SAML web authentication: SAMLWebIdP
2014-08-21 09:29:41,844 [main] INFO unity.server.EngineInitialization  
-  - UNITY UNICORE web authentication: SAMLUnicoreWebIdP
2014-08-21 09:29:41,891 [main] FATAL unity.server.EngineInitialization  
- Can't load endpoints which are configured
pl.edu.icm.unity.exceptions.EngineException: Unable to deploy an 
endpoint: The authenticator of type web-vaadin7 is not supported by the 
binding. Supported are: [webservice-cxf2]
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deployInt(EndpointManagementImpl.java:132)
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deploy(EndpointManagementImpl.java:101)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.loadEndpointsFromConfiguration(EngineInitialization.java:631)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeEndpoints(EngineInitialization.java:579)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.initializeDatabaseContents(EngineInitialization.java:282)
         at 
pl.edu.icm.unity.engine.internal.EngineInitialization.start(EngineInitialization.java:181)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
         at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:346)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:149)
         at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:112)
         at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:773)
         at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:485)
         at 
pl.edu.icm.unity.server.UnityApplication.run(UnityApplication.java:50)
         at 
pl.edu.icm.unity.server.UnityApplication.main(UnityApplication.java:58)
Caused by: pl.edu.icm.unity.exceptions.WrongArgumentException: The 
authenticator of type web-vaadin7 is not supported by the binding. 
Supported are: [webservice-cxf2]
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.verifyAuthenticators(EndpointManagementImpl.java:147)
         at 
pl.edu.icm.unity.engine.EndpointManagementImpl.deployInt(EndpointManagementImpl.java:120)
         ... 14 more

Is there any mistake in configuration?

Thanks in advance!

Best regards,
Atul

[Unity-idm-discuss] Bugfix release 1.3.1

[Krzysztof B. <go...@ic...>]

Dear All,

For the first time in the short life of Unity a revision (bugfix only) 
release is issued.

The release fixes one quite important regression introduced in the 
1.3.0: the registration forms attached to remote authentication pipeline 
were never invoked. Also a couple of less important bugs were fixed.

The docoumentation was updated with a simplified update procedure for 
the revision releases.

Details and download link are in the usual location:
http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof