[Tf-aai] CLARIN+ and AAI

[Jozef Misutka]

Dear all,

a bit later than expected but I would like to inform you about CLARIN+
progress related to AAI. I would welcome any feedback or questions and
discussion in general.

These are the main goals of CLARIN+ AAI:
1. use Unity IDM instead of the current CLARIN solution for identity
management
2. summarise CLARIN AAI requirements into a formal document
3. implement simple attribute release framework and integrate it with (a
few) CLARIN SPs
4. re-engineer SAML integration of IDPs and update discovery feeds if needed
5. in the long run, try to simplify and automate metadata propagation

More details:

1. Unity IDM

Unity IDM has been chosen as the backend for identity management last year.
There are several reasons for that including some not related to AAI.
Several systems have been evaluated and Unity met most of the requirements.
It is a java servlet running, by default, on jetty using spring. It offers
several endpoints that applications can connect to (this is interesting
because it contains SAML2*, OpenID, OAuth, web* endpoints) and it can also
connect to various backends (
http://www.unity-idm.eu/documentation/unity-1.8.0/manual.html) or use its
own.
The missing part was LDAP endpoint that I have been implementing because
several CLARIN services (svn, trac, nexus, drupal, ..)  are using LDAP
authentication (and authorisation).

The LDAP server implementation has been pushed to unity source repository
and is being reviewed and fine tuned. The next steps include more testing,
importing of the old identities and adjust the UI including registration
forms.

2. AAI requirements

I will send the first draft this week.

3. Attribute release framework

SPF contains many SPs. A huge effort is needed to actively pursue failed
logins, missing attributes at each of the SPs. I dare to say that also
based on CLARIN's voice about attribute release there has been some
development on the inter-federation level e.g., eduGAIN attribute release
check that checks IdP against multiple SPs - normal one, with CoCo, with
R&S. But I do not expect that many different IdPs will test it and it can
also return different results than when tested on your own SPs. A more
systematic approach is needed and is possible. With either javascript on
the user side or on the server side (e.g., php) of the SP, we can get the
names of attributes that were propagated to the application (or were
released when using server side solution which means that all the
attributes even before filtering) and we can store them in a simple web
application. This TF members can then actively hunt the bad IdPs with semi
automated emails.

4. IdP feeds

This will be discussed later.

5.

DFN is in the process of approving a formal document that somewhat binds
DFN to propagate SPF SPs to eduGAIN and we can build on that and offer a
 reasonably sustainable service.
We will try to convince federation operators to harvest SPF SPs
(semi)automatic from eduGAIN which will lessen the burden for manual
changes at every SPF member.

Best,
Jozef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clarin.eu/cgi-bin/mailman/private/tf-aai/attachments/20160315/c4852fa6/attachment.htm>