unity-idm-discuss — Unity discussion and support

Re: [Unity-idm-discuss] Authentication fails

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

Dear Gerben,

W dniu 11.06.2015 o 11:50, Gerben Venekamp pisze:
> Dear all,
>
> I am having difficulties in setting up Unity for federated access. What
> I have done thus far is make use of an external SAML IdP, which provides
> federated authentication. The external IdP is SURFconext. My
> configuration seems to be working in so far that I am able to see and
> use the WAYF page. This is still within a test environment. After having
> selected an IdP from the WAYF page, I am asked for credentials. This
> also works as expected. When I return however, Unity logs the below lines:
>
> 2015-06-11 11:20:00,838 [qtp406265225-43] DEBUG
> unity.server.saml.RedirectRequestHandler  - Starting SAML HTTP Redirect
> binding exchange with IdP
> https://engine.surfconext.nl/authentication/idp/single-sign-on
> 2015-06-11 11:20:16,973 [qtp406265225-44] DEBUG
> unity.server.saml.SamlHttpServlet  - Got SAML response using the HTTP
> POST binding
> 2015-06-11 11:20:17,233 [qtp406265225-44] WARN
> unity.server.saml.SAMLRetrievalUI  - SAML response verification or
> processing failed
> pl.edu.icm.unity.server.authn.AuthenticationException: The SAML response
> is either invalid or is issued by an untrusted identity provider.
>
> Looking at the HTTP response, I can received the following:
>
> *POSThttps://unity.sara.cloudlet.sara.nl:2443/unitygw/spSAMLResponseConsumer  HTTP/1.1
> **Host*:unity.sara.cloudlet.sara.nl  <http://unity.sara.cloudlet.sara.nl>:2443
> *User-Agent*: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
> *Accept*: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> *Accept-Language*: en-US,en;q=0.5
> *Accept-Encoding*: gzip, deflate
> *Referer*:https://engine.surfconext.nl/authentication/sp/consume-assertion
> *Cookie*: lastAuthenticationUsed=samlWeb_remoteIdp.1.
> *Content-Type*: application/x-www-form-urlencoded
> *Content-Length*: 7755
>
> *HTTP/?.? 302 Found
> **X-Frame-Options*: DENY
> *Location*:https://unity.sara.cloudlet.sara.nl:2443/home/home/
> *Content-Length*: 0
>
> What I am trying to do is to have a user login in a federated manner as
> a test to see if my configuration works. The SAML response lists the
> requested attributes, so that seems fine.
>
> What I can make of the debug info is that the certificate is not
> trusted. I am not sure which certificate that is. The federated IdP
>   should work with self signed certificates, this I checked with the
> service itself. It puzzels me why I also see the DENY for the redirect.
> Is that based on the fact of the untrusted certificate? This seems
> likely and what do I need to do to get a trusted certificate, i.e. what
> part of the configuration did I do not get right?

To debug in more details the Shiraz suggestion:
log4j.logger.unity.server.saml=DEBUG

is what you need to do. Or even set it to TRACE, than you will see 
everything that goes on the wire. Furthermore with the lines of the 
stack trace, that should be in your log file just below what you have 
pasted it should be possible to give some hints even now.

In general there are tons of possibilities why verification fails, most 
probably it is configuration problem. So your *remote saml authenticator 
settings* are relevant. Maybe this is that the certificate of the 
surfconext service that is not trusted as you guess.

Regarding the 'DENY' in
*X-Frame-Options*: DENY
it is security measure to prevent clickjacking attacks, nothing related.

Best,
Krzysztof

Re: [Unity-idm-discuss] Authentication fails

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

Hi Gerben,

I would like to know which Unity version are you running and what is the SURFConext's remote IdP configuration inside the remoteSamlAuth.properties?

A tip: use the metadataSource style of configuration:

unity.saml.requester.metadataSource.surfconext.url=https://url_to_your_idp_metadata_file
unity.saml.requester.metadataSource.surfconext.perMetadataTranslationProfile=some_InputAttributeTranslationProfile (optional)
unity.saml.requester.metadataSource.surfconext.perMetadataRegistrationForm=some_RegistrationForm (optional)

set the following property in log4j.properties file to see more detailed saml specific exchanges
log4j.logger.unity.server.saml=DEBUG

Furthermore, you may enable signature verification by,

unity.saml.requester.metadataSource.surfconext.signaturVerification=require
unity.saml.requester.metadataSource.surfconext.signatureVerificationCertificate=SURFCONEXT_IDP_CERTIFICATE (should be defined in the conf/pki.properties file)

Finally refresh the authenticators and endpoints.

Cheers,
Shiraz


On Thu, Jun 11, 2015 at 11:50 AM, Gerben Venekamp <ger...@su...<mailto:ger...@su...>> wrote:
Dear all,

I am having difficulties in setting up Unity for federated access. What I have done thus far is make use of an external SAML IdP, which provides federated authentication. The external IdP is SURFconext. My configuration seems to be working in so far that I am able to see and use the WAYF page. This is still within a test environment. After having selected an IdP from the WAYF page, I am asked for credentials. This also works as expected. When I return however, Unity logs the below lines:

2015-06-11 11:20:00,838 [qtp406265225-43] DEBUG unity.server.saml.RedirectRequestHandler  - Starting SAML HTTP Redirect binding exchange with IdP https://engine.surfconext.nl/authentication/idp/single-sign-on
2015-06-11 11:20:16,973 [qtp406265225-44] DEBUG unity.server.saml.SamlHttpServlet  - Got SAML response using the HTTP POST binding
2015-06-11 11:20:17,233 [qtp406265225-44] WARN  unity.server.saml.SAMLRetrievalUI  - SAML response verification or processing failed
pl.edu.icm.unity.server.authn.AuthenticationException: The SAML response is either invalid or is issued by an untrusted identity provider.

Looking at the HTTP response, I can received the following:

POST https://unity.sara.cloudlet.sara.nl:2443/unitygw/spSAMLResponseConsumer HTTP/1.1
Host: unity.sara.cloudlet.sara.nl<http://unity.sara.cloudlet.sara.nl>:2443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://engine.surfconext.nl/authentication/sp/consume-assertion
Cookie: lastAuthenticationUsed=samlWeb_remoteIdp.1.
Content-Type: application/x-www-form-urlencoded
Content-Length: 7755

HTTP/?.? 302 Found
X-Frame-Options: DENY
Location: https://unity.sara.cloudlet.sara.nl:2443/home/home/
Content-Length: 0

What I am trying to do is to have a user login in a federated manner as a test to see if my configuration works. The SAML response lists the requested attributes, so that seems fine.

What I can make of the debug info is that the certificate is not trusted. I am not sure which certificate that is. The federated IdP  should work with self signed certificates, this I checked with the service itself. It puzzels me why I also see the DENY for the redirect. Is that based on the fact of the untrusted certificate? This seems likely and what do I need to do to get a trusted certificate, i.e. what part of the configuration did I do not get right?

Many thanks,
Gerben Venekamp

------------------------------------------------------------------------------

_______________________________________________
Unity-idm-discuss mailing list
Uni...@li...<mailto:Uni...@li...>
https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss




--
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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

[Unity-idm-discuss] Authentication fails

[Gerben V. <ger...@su...>]

Dear all,

I am having difficulties in setting up Unity for federated access. What I have done thus far is make use of an external SAML IdP, which provides federated authentication. The external IdP is SURFconext. My configuration seems to be working in so far that I am able to see and use the WAYF page. This is still within a test environment. After having selected an IdP from the WAYF page, I am asked for credentials. This also works as expected. When I return however, Unity logs the below lines:

2015-06-11 11:20:00,838 [qtp406265225-43] DEBUG unity.server.saml.RedirectRequestHandler  - Starting SAML HTTP Redirect binding exchange with IdP https://engine.surfconext.nl/authentication/idp/single-sign-on
2015-06-11 11:20:16,973 [qtp406265225-44] DEBUG unity.server.saml.SamlHttpServlet  - Got SAML response using the HTTP POST binding
2015-06-11 11:20:17,233 [qtp406265225-44] WARN  unity.server.saml.SAMLRetrievalUI  - SAML response verification or processing failed
pl.edu.icm.unity.server.authn.AuthenticationException: The SAML response is either invalid or is issued by an untrusted identity provider.

Looking at the HTTP response, I can received the following:
POST https://unity.sara.cloudlet.sara.nl:2443/unitygw/spSAMLResponseConsumer HTTP/1.1
Host: unity.sara.cloudlet.sara.nl:2443
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://engine.surfconext.nl/authentication/sp/consume-assertion
Cookie: lastAuthenticationUsed=samlWeb_remoteIdp.1.
Content-Type: application/x-www-form-urlencoded
Content-Length: 7755

HTTP/?.? 302 Found
X-Frame-Options: DENY
Location: https://unity.sara.cloudlet.sara.nl:2443/home/home/
Content-Length: 0
What I am trying to do is to have a user login in a federated manner as a test to see if my configuration works. The SAML response lists the requested attributes, so that seems fine.

What I can make of the debug info is that the certificate is not trusted. I am not sure which certificate that is. The federated IdP  should work with self signed certificates, this I checked with the service itself. It puzzels me why I also see the DENY for the redirect. Is that based on the fact of the untrusted certificate? This seems likely and what do I need to do to get a trusted certificate, i.e. what part of the configuration did I do not get right?

Many thanks,
Gerben Venekamp

Re: [Unity-idm-discuss] Release 1.6.0 available

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

>
> Well, why at server startup? What is the use case?
>
> I'd prefer to add such feature to the REST API if you prefer to do it in
> some automated way. Or there can be some bulk import/export from UI
> (actually this is implemented, but only as a part of the import/export of
> the whole database). I need to know your requirements in more details first
> to suggest something concrete.
>

ok

* use case #1: "Provisioning on Server Installation"
by installing a new instance,
i would like to create a number (~50) of attributes,
mostly coming from ldap-schema.

* use case #2: "Provisioning on new Application Rollout"
having developed a new application that needs additional attributes,
or need to update an existing attribute enum,
or need to update an existing attribute regex-check


having attribute-definition in the rest api would actually be sufficient,
since one can package a script as part of the install or upgrade procedure.

would this make it into 1.7.0 ?

cheers,
--
Terefang

Re: [Unity-idm-discuss] Release 1.6.0 available

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

Hi Terefang,

W dniu 09.06.2015 o 12:45, Terefang Verigorn pisze:
> hi!
>
> many thanks for the new release!
>
> in particular the rest api will allow me to drop my custom plugins.

You're welcome! it great that you can reduce code to maintain.

>
> i am still looking for a way to load new attribute-definitions
> (based on existing syntax) into the server.
>
> i would like to do this via config-file (during server startup).
>
> any idea ?

Well, why at server startup? What is the use case?

I'd prefer to add such feature to the REST API if you prefer to do it in 
some automated way. Or there can be some bulk import/export from UI 
(actually this is implemented, but only as a part of the import/export 
of the whole database). I need to know your requirements in more details 
first to suggest something concrete.

Best,
Krzysztof

Re: [Unity-idm-discuss] Release 1.6.0 available

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

hi!

many thanks for the new release!

in particular the rest api will allow me to drop my custom plugins.

i am still looking for a way to load new attribute-definitions
(based on existing syntax) into the server.

i would like to do this via config-file (during server startup).

any idea ?

PS: keep up with the good work

C,
--
Terefang

[Unity-idm-discuss] Release 1.6.0 available

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

Dear All,

The release 1.6.0 of Unity server is ready for download.

The highlights of this release are:

* Unity appearance and its control was generally improved.
   - New modern theme
   - The login screen was fully reorganized to be more user friendly and 
flexible: you can use authentication tiles, and choose tile contents 
presentation mode
   - Custom style modifications are possible now, also per endpoint
   - Web page loading time was significantly improved

* Merging of accounts (entities) is possible now, in a number of 
variants: admin and user driven.

* Besides self-modifiable attributes it is possible now to use 
self-modifiable identities.

* Enhanced REST API with write operations

Please note that this is the 1.6.x releases are the last supporting Java 
7. From the 1.7.0 version Unity will require Java 8 to be started.

Please make sure to read the detailed update instruction, which can be 
found in documentation before upgrading.


Big thanks to everybody involved in this release!


The full list of changes with additional details are available as always 
at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

[Unity-idm-discuss] Java 8 migration

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

Dear All,

Early notice about our future plans: Unity will be moved to Java 8 from 
the release 1.7.0.

Note that 1.7.0 is not the next release, which will be 1.6.0. 1.7.0 can 
be expected no sooner then at the end of May.

Current support for Java 8 in distributions is improving: already now 
Centos 6 and 7 contains Java 8 as well as Fedora. Debian stable does not 
but Java 8 can be installed from additional repositories (besides the 
Oracle packages which are always available, however less convenient for 
administrators).

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Unity as UNICORE/X attribute source

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

Hi Björn,

W dniu 06.02.2015 o 14:04, Björn Hagemeier pisze:
> Hi all,
>
> last summer (July 10), Krzysztof reported that pull mode should be
> possible acc. to the UNICORE/X documentation. However, I found some
> missing bits and pieces to really make it work (for me). As far as I can
> see from my changes in the unityServer.conf, the most important
> configuration is to allow certificate based authentication on the
> SAMLUnicoreSoapIdP endpoint. In order to achieve that, I needed a certWS
> authenticator, which seemed to have been missing so far.
>
> Here's a diff of the relevant portions in unityServer.conf:
>
> ==================================================
> +unityServer.core.authenticators.5.authenticatorName=certWS
> +unityServer.core.authenticators.5.authenticatorType=certificate with
> cxf-certificate
> +unityServer.core.authenticators.5.localCredential=Certificate credential
> +unityServer.core.authenticators.5.retrievalConfigurationFile=conf/authenticators/empty.json
> [...]	
>   unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
> -unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
> +unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-unicoreidp.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
> +unityServer.core.endpoints.4.endpointAuthenticators=certWS;pwdWS
>   ==================================================
>
> This configuration is working well for me. However, I am wondering
> whether this can be correct or is even required. After all I guessed the
> setup of the additional authenticator and the changes to the endpoint.
> Ok, looking back into the documentation (Sect. 3.5) I do see the
> relevant snippet, though the example is not quite right (s/pwdWS/certWS/).
>
> The endpoint for the AssertionQueryService needs to be guessed. Maybe it
> is obvious for knowledgeable people, but it does not appear in either
> the Unity or the UNICORE/X manual.

Regarding this part:
1) the typo in section 3.5 of documentation was fixed, thanks for 
spotting it

2) regarding the *default* configuration of the UNICORE SOAP Idp 
endpoint, what you have in the distro is suited for use with UCC and 
cert-less login. Your changes to enable the pull mode from the server 
are correct: UNICORE server can identify itself only with a certificate 
so certificate authenticator is required.
That's said I don't see any problem with changing the defaults here, 
i.e. to add a 'certWS' authenticator to the default configuration. Will 
be in the next release.

3) Endpoint address - right, it is not trivial to find it. You can see 
the base path of the address in the Server Management->Endpoints tab, 
after expanding the appropriate endpoint. You have to open this base 
address: CXF reports all the services, including the detailed addresses.


And yes, you are right - there is no UNICORE+Unity howto, and it is 
needed. The address should be provided there.


> Which are the settings for the services consuming attributes? Which
> roles do they need? Can they have local roles within a VO/Group? Acc. to
> the developer Wiki there are (were?) issues with this setup as well as
> the setup for group administration[1]. Do services need to be members of
> the groups which they query? How do I best set their xlogin (nobody?) if
> I want to use an attribute class requiring xlogin and role to be set?

The settings should be the same as in case of using any other attribute 
source. In most cases the role should be 'server' and xlogin unset or 
nobody - however this depends on a site.

You can set the local roles in a group - this is a generic Unity 
feature, always available.

The issues mentioned in the developer's oriented wiki are related to a 
limited authorization of Unity management. I.e. there are some 
limitations if you want to have a person who can administer only a 
specific group of Unity groups tree.

No, services (and all other clients) need not to be members of groups 
they query. They need to have read permission there. So they need (at 
least) read permission on the group or on any of parent group.

There are many possible approaches to set xlogin and role for services 
and users, this really depends on your scenario. Couple of hints:
- If you have different mappings per site then create group for each site.
- Use group attribute statements to assign default or common values.
- Also to copy attributes to have uniform view.

Consider a quite sophisticated example:

/siteA/servers <- all servers with attribute statement assigning fixed 
role=server and xlogin=nobody
/siteA/users <- all users, attribute statement assigning role=user and 
xlogin set individually
/siteA <- used in endpoint's configuration. Has attribute statements 
that copy the role and xlogin attribute from servers and users subgroups.

> BTW, speaking of attribute classes. It is quite some hassle to modify an
> attribute class for any given group. I think I do understand why this is
> so, but from the point of view of usability it seems like a nightmare
> (please don't take this as an offense). I did find a workaround
> (temporary group), but maybe that should not be required. This is more
> of a general issue than a UNICORE specific one. I haven't had a look at
> the latest release 1.5.0 yet, maybe some of that has gone by now.

Hard to comment - what is the problem? If you want to set mandatory 
attributes requirement it is a hassle by definition (mandatory is 
mandatory, dot). Rule of thumb: use mandatory attributes *only* for 
attributes that you have to define manually, and the attribute really 
must be always set. Attributes which have sensible defaults, especially 
those assigned by attribute statements, should be included in the 
'allowed' enumeration of the class.


> Once these issues have been sorted out, I'd like to provide a concise
> howto on the relevant steps to get UNICORE/X going with UNITY as the
> attribute source. IMO, this is a very valuable use case, but the
> description not fully there, at least not in one piece.
Yes, this is a very much needed effort. Of course I'll contribute.

Cheers,
Krzysztof

[Unity-idm-discuss] Unity as UNICORE/X attribute source

[Björn H. <b.h...@fz...>]

Hi all,

last summer (July 10), Krzysztof reported that pull mode should be
possible acc. to the UNICORE/X documentation. However, I found some
missing bits and pieces to really make it work (for me). As far as I can
see from my changes in the unityServer.conf, the most important
configuration is to allow certificate based authentication on the
SAMLUnicoreSoapIdP endpoint. In order to achieve that, I needed a certWS
authenticator, which seemed to have been missing so far.

Here's a diff of the relevant portions in unityServer.conf:

==================================================
+unityServer.core.authenticators.5.authenticatorName=certWS
+unityServer.core.authenticators.5.authenticatorType=certificate with
cxf-certificate
+unityServer.core.authenticators.5.localCredential=Certificate credential
+unityServer.core.authenticators.5.retrievalConfigurationFile=conf/authenticators/empty.json
[...]	
 unityServer.core.endpoints.4.endpointType=SAMLUnicoreSoapIdP
-unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-webidp.properties
+unityServer.core.endpoints.4.endpointConfigurationFile=conf/endpoints/saml-unicoreidp.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
+unityServer.core.endpoints.4.endpointAuthenticators=certWS;pwdWS
 ==================================================

This configuration is working well for me. However, I am wondering
whether this can be correct or is even required. After all I guessed the
setup of the additional authenticator and the changes to the endpoint.
Ok, looking back into the documentation (Sect. 3.5) I do see the
relevant snippet, though the example is not quite right (s/pwdWS/certWS/).

The endpoint for the AssertionQueryService needs to be guessed. Maybe it
is obvious for knowledgeable people, but it does not appear in either
the Unity or the UNICORE/X manual.

Which are the settings for the services consuming attributes? Which
roles do they need? Can they have local roles within a VO/Group? Acc. to
the developer Wiki there are (were?) issues with this setup as well as
the setup for group administration[1]. Do services need to be members of
the groups which they query? How do I best set their xlogin (nobody?) if
I want to use an attribute class requiring xlogin and role to be set?

BTW, speaking of attribute classes. It is quite some hassle to modify an
attribute class for any given group. I think I do understand why this is
so, but from the point of view of usability it seems like a nightmare
(please don't take this as an offense). I did find a workaround
(temporary group), but maybe that should not be required. This is more
of a general issue than a UNICORE specific one. I haven't had a look at
the latest release 1.5.0 yet, maybe some of that has gone by now.

Once these issues have been sorted out, I'd like to provide a concise
howto on the relevant steps to get UNICORE/X going with UNITY as the
attribute source. IMO, this is a very valuable use case, but the
description not fully there, at least not in one piece.


Cheers,
Björn

[1] https://www.assembla.com/spaces/unity-public/wiki/Authorization


-- 
Dipl.-Inform. Björn Hagemeier
Federated Systems and Data
Juelich Supercomputing Centre
Institute for Advanced Simulation

Phone: +49 2461 61 1584
Fax  : +49 2461 61 6656
Email: b.h...@fz...
Skype: bhagemeier
WWW  : http://www.fz-juelich.de/jsc

JSC is the coordinator of the
John von Neumann Institute for Computing
and member of the
Gauss Centre for Supercomputing

-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------

[Unity-idm-discuss] Release 1.5.0 available

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

Dear All,

The release 1.5.0  was published on 30.01.2015

Unity 1.5.0 is the first release in which not only a core functionality 
but also the user experience started to be addressed.

The release highlights are:

* Translation profiles creation - the most complicated step of remote 
IdP configuration - is now supported by two new facilities: 
Debugger and Profile creation wizard.

* Frequently requested e-mail confirmations are now available. Unity 
provides a complete and generic support for this service.

* Internalization of Unity was improved. From now on all end-user 
visible names (e.g. credential or attribute names) are now independent 
from internal identifiers and can be provided in all languages which are 
enabled in the server. What is more a complete (with exception of Admin 
UI) Polish translation is now available.

* HomeUI (user's profile) starts to be really functional: users can see 
configured attributes, edit some of them, remove their account and more.

Big thanks to all our contributors, in particular Roman Krysiński for 
his magnificent work on translation profile debugging and wizard and 
Piotr Piernik for his work on e-mail confirmations.

The full list of changes (there are many more!) & updated documentation 
are available as always at http://www.unity-idm.eu/site/downloads

Best regards,
Krzysztof

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

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

Hi,

W dniu 27.01.2015 o 20:26, Terefang Verigorn pisze:
> hi!
>
> ok my auth enumberation is working and already authenticating :-)))

Great to hear this!


> 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.

This won't influence command line in anyway as classpath is exported as 
an env var.

However, the requirement to have loading of jars from extensions 
directories sounds reasonable. I'll have to perform some tests and 
likely it will be included in 1.6.0.

Thanks!
Krzysztof

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