[Tf-aai] AAI and user consent

Tue Apr 5 14:49:50 CEST 2016

Hi all,

Sander mentions below his hope that Shibboleth3's inbuild uApprove will win over IdPs. I hope that too, but I'd like to share some not so good facts on the subject.

I had some discussions with German and also Danish IdP operators and they both told me that they see consent not as the only solution.
The argumentation goes along the lines that the operator has to nevertheless make sure attribute release is safe.
So an IdP who releases to a non-trustworthy SP is not off the hook even if the user trusts the SP.

>From Germany I heard the argument that a researcher can claim he was "forced" to consent if he needs the resource for his research.
(Which is of course weird, how can it be then better not to offer a resource?) But this is how legal people seem to work.

The bottom line is, fine grained consent options might not always sway the IdP operator/data protection representative.
Be assured that I don't agree with this train of thought, I just wanted to share it with you.
Yes, IdPs cannot hide behind user consent but the way some IdPs are protecting users from themselves is still beyond me.

Sorry about being vague with my sources, but I can dig them out if you would like to engage in a more detailed discussion.

Regards,
Martin

-- 
Martin Matthiesen
CSC - Tieteen tietotekniikan keskus
CSC - IT Center for Science
PL 405, 02101 Espoo, Finland
+358 9 457 2376, martin.matthiesen at csc.fi
Public key : https://pgp.mit.edu/pks/lookup?op=get&search=0x74B12876FD890704
Fingerprint: AA25 6F56 5C9A 8B42 009F  BA70 74B1 2876 FD89 0704

----- Original Message -----
> From: "Jozef Misutka" <misutka at ufal.mff.cuni.cz>
> To: "Sander Maijers" <sander at clarin.eu>
> Cc: "tf-aai" <tf-aai at lists.clarin.eu>, spf at clarin.eu
> Sent: Monday, 4 April, 2016 12:42:48
> Subject: Re: [Tf-aai] CLARIN+ and AAI

> 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
>>>
>>
>>
> 
> 
> [Text File:ATT00001]