[Tf-aai] CLARIN+ and AAI

[Jozef Misutka]

On 21 March 2016 at 13:17, Sander Maijers <sander at clarin.eu> wrote:

> 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.
>
>
I am not sure what you mean by that - the web endpoint of Unity which
allows you to login to Unity and see/update your profile?


>
>    1.
>    2. encryption of the LDAP traffic: a must for compliance. How hard is
>    e.g. using TLS going to be?
>
>
*Should* be a matter of configuration.



> 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.
>>
>
My fault to give an exact date ;) - still in progress.


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

Hopefully, but the https://www.switch.ch/aai/support/tools/uapprove/ has
been here for quite some time too...


>
>
>> 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/20160404/e3ef6bd7/attachment.htm>