[Tf-aai] CLARIN+ and AAI

[Sander Maijers]

Hi Jozef,

Just returned from vacation. Thanks for your update! I'm very pleased with your
documentation
<https://trac.clarin.eu/wiki/ServiceProviderFederation/CLARIN%20IdP#Implementation>
effort
on the Trac as well.
Some comments below.

Best,
Sander
--
*Sent as system administrator and engineer for CLARIN*
*Please send inquiries about specific services to the corresponding e-mail
address*
*See https://www.clarin.eu/content/support
<https://www.clarin.eu/content/support>*

Max Planck Institute for Psycholinguistics <https://tla.mpi.nl/>, software
developer
personal Skype: sander.maijers | work address: Wundtlaan 1, 6525 XD,
Nijmegen (NL)



On Tue, Mar 15, 2016 at 8:29 PM, Jozef Misutka <misutka at ufal.mff.cuni.cz>
wrote:

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

Some issues that I believe are still open at this point:

   1. Unity IDM UI work: will it work, how? I am not aware of the detail
   enough to be sure about this.
   2. encryption of the LDAP traffic: a must for compliance. How hard is
   e.g. using TLS going to be?

I hope we can iron out esp. the last item soon, and provide some details of
the remaining work (e.g., what was and must still be tested) on the Trac.

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

A very important practical development is the inclusion of attribute
release consent functionality in the modern hibboleth IdP. See
https://wiki.shibboleth.net/confluence/display/IDP30/ConsentConfiguration
Since IdP V3 will be used a lot (i.e., is the only version supported, as
far as the very popular Shibboleth implementation is concerned) this can be
used as a compelling factor for IdP operators to (at minimum) offer consent
forms instead outright refusal to release certain attributes in certain
cases. E.g. offering all the reassuring Entity Categories on the SAML
metadata about CLARIN SPs plus only asking IdP operators to offer user
attribute release *consent* instead of *automatic* attribute release, may
finally win them over.


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

I've mentioned earlier in AAI TF discussions that (A) retrieving of SAML
metadata about CLARIN SPs directly from them instead of (B) via manual
submission would be better (more scalable, better relation between actual
and given SP config, less redundancy in places where SAML metadata must be
maintained). The SAML Metadata Query Protocol (MQP) seems become the
standard in this regard. It would be good if we all keep an eye on this
<https://wiki.shibboleth.net/confluence/display/IDP30/DynamicHTTPMetadataProvider>
at
least mention the impact of such changing technologies/paradigms in our
reporting, even if it doesn't affect us ultimately. Since the CLARIN IdP is
going to become Unity IDM, we cannot sustainably use the production
instances of the current Shibboleth-based CLARIN IdP as some kind central
aggregator for SAML metadata about SPF SPs. But who knows, perhaps the
changing technological context (including MQP) does have an impact on the
feasibility of workflow A (with our without manual approval in the loop,
e.g. via SVN revisions).


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