[Tf-aai] LoA Questionaire
Sander Maijers
sander at clarin.eu
Thu Sep 17 10:51:21 CEST 2015
Hi Martin,
I found the survey interesting and so I have some comments. Most of my
comments are inspired by thinking about what the SPF should imply are
our demands/requirements by giving specific answers. Also, most
comments hint at possible lack of evidence to support certain answers,
which is I think critical if we want to more or less ‘petition’ for
any policy changes on the identity federation/IdP side.
Best,
Sander
--
Sent as system administrator and engineer for CLARIN
Centre Registry & Service Provider Federation @ {centres,infra}.clarin.eu;
software engineering tools @ {svn,trac}.clarin.eu;
identity and access management @ {user,idp}.clarin.eu
usage statistics and service monitoring @ stats.clarin.eu
Max Planck Institute for Psycholinguistics, software developer
personal Skype: sander.maijers | work address: Wundtlaan 1, 6525 XD,
Nijmegen (NL)
On Wed, Sep 16, 2015 at 3:33 PM, Martin Matthiesen
<martin.matthiesen at csc.fi> wrote:
> Hello Taskforce,
>
> I was asked by Mikael Linden to participate in an interview to find out Clarin's needs with regard to Level of Assurance. The interview will likely happen next week and I would like to share with you how I am intending to answer. The general line is that LoA is important or at least will be important. As to auditing I see that self-assertion can work a long way, similar to the Data Seal of Approval process.
>
> The original can be viewed here: https://wiki.geant.org/display/AARC/Level+of+Assurance+survey+for+SP+communities
>
> Cheers,
> Martin
>
>> 2. Questions on the research infrastructures/communities
>>
>> Who are your end users (who need to log in to your services):
>>
>> researchers with a Home Organisation (that operates or potentially operates an IdP)?
>
> yes
>
>> citizen scientists?
>
> potentially.
We have a good amount of private accounts in the LDAP directory for
the CLARIN IdP. This seems like a normal phenomenon (they just won't
have the ‘academic’ entitlement)). So for this group the answer can be
considered ‘yes’, at least, it is not founded in fact to discriminate
(in the technical sense of the word) them with an ambiguous
‘potentially’.
>
>> students with a Home Organisation (that operates or potentially operates an IdP)?
>
> yes.
>
>> else/what?
>>
>> 3.Questions on Identity and Authentication
>>
>> User's "network identity" distinguishes him/her from other users of the SP.
>> 3.1. Identity concept
>>
>> How important is it for you that
>>
>> all user identities (accounts in the Home Organisation) belongs to an individual person (i.e. there are no shared accounts like "libraryuser1")?
>
> important
>
>> and all users are traceable (i.e. the Home Organization knows who they are and can reach them)?
>
> important
>
>> and the Home Organisation is willing to collaborate with you if you think their user misbehaves in your service?
>
> important
>
>> that you (as an SP) can block him/her from your service?
>
> important
Is it? How often does abuse happen at SPs, and does it get detected,
while the account itself would persist (i.e., not be suspended after a
complaint to the IdP operator)?
>>
>> user identifiers are persistent i.e. a user account is not re-assigned (re-cycled) to another person over time?
>
> important. Recycling of old IDs should be phased out.
Does that happen (statistics)? If SP operators still identify users by
ePPN, is it a good position to claim recycling should be phased out,
when it is allowed by the ePPN semantics? Seems like a weak position
to me.
>
>> user identifiers are shared by multiple SPs i.e. if you have 2 SPs, do they both receive the same user identifier when the same user logs in to the two services?
>
> important
>
>>
>> 3.2.Initial proof of identity
>>
>> How important is it for you that
>>
>> the Home Organization has a documented identity vetting process (whatever it is) in English and you can study it?
>
> important
>
>> each Home Organisation has a machine-readable tag that indicates how the organization carries out identity proofing and the tag is from a well-defined international vocabulary?
>
> important
>
>> each user in a Home Organisation has the above tag and different end users in the same organization can have different tags (depending how their identity was initially proofed)?
>
> important
>
>> the identity proofing is done face-to-face based on a government photo-ID or equivalent?
>
> Highly depends on the service. For sensitive data strong identification is needed, for less sensitive data a simpler procedure might be enough.
>
>>
>> 3.3.On-line authentication
>>
>> Are password-based authentication good enough for you?
>
> Again, it depends. For now, yes.
I think a lot can be said about this. Personally, I think password
based authentication should be disfavored. Many experts seem to think
so, if I'm not mistaken both Google and Microsoft have expressed their
intention to move past password-based authentication. Read e.g.
http://www.wired.com/2012/11/ff-mat-honan-password-hacker/ .
This topic seems not only relevant for technical reasons, but whether
or not password-based authentication is used or some alternative also
has an impact on usability.
I believe this is a topic that merits investigation under the banner of CLARIN+.
>> Should passwords have some kind of quality floor? (What kind of quality floor?)
>
> The organisation should state whether it requires a quality floor and what that is.
Don't know if this is an open or closed question, but why not be a bit
stricter/more explicit in ‘our demands’ on this? If the IdP operators
would indeed write such policy documents, then what would SPF SP
operators really do with it? Block specific IdPs? That seems like a
lot of overhead, and like it's not going to happen. In that case the
IdP operator's efforts would go to waste.
>> Do you need two factor authentication? (What kind of?) Are you willing to share its costs?
>
> For now, no. But that might change in the future.
>
>> 3.4.Step-up authentication as a service
>>
>> Step-up authentication means that the user first authenticates with a password, and subsequently with a second factor (such as by a one-time password delivered to his/her cellphone). Step-up authentication could be delivered to research communities as a service.
>>
>> Would you like to make use of step-up authentication
>>
>> if it costs you money?
>> if it costs you work (for instance, you need to operate one or several registration authorities where your community's users come to show their photo-ID and you record their cellphone number)?
>
> So far there was no need for 2 factor authentication.
Not an unreasonable answer I think. But could you support this answer
(e.g. with evidence)?
>> 4. Questions on user attributes
>>
>> Besides an identifier, the Home Organisation's Identity Provider is able to deliver also other attributes of the person that logs in.
>> 4.1. Freshness of user accounts and attributes
>>
>> Many Home Organisations close the user account when an individual departs (e.g. researcher changes his/her employer). Closing the account closes also federated access to your SP. However, some organisations keep the accounts open (e.g. to serve alumni etc).
>>
>> Do you expect that user accounts are closed as a user departs? How promptly?
>
> Prompty, roughly within a week.
>
>> Do you expect that user's role attributes (e.g. eduPersonAffiliation="faculty") value is updated as an individual departs? How promptly?
>
> Prompty, roughly within a week.
>
>
>>
>> 4.2. Quality/provenance of user data
>>
>> In larger universities the IdP/IdP gathers users' attributes from several registries (payroll system, CRIS system, student registry) with varying data quality. Some attributes can even be self-asserted by the user him/herself.
>>
>> Is it important for you to know the quality/provenance of the user data on the attribute level? What attributes? On what level of granularity?
>
> Freely changeable attributes should be marked, if that is possible. Self-asserted attributes are not a problem as long as the self-assertion has been signed by the user.
I did not understand what signed by the user means in this context.
Could you explain? (Was this a closed question?)
>> 4.3. Population and release of attributes
>>
>> What are the key attributes Home Organisations should populate for their end users and release to your SP?
>
> The recommendations of the Data Protection Code of Conduct should be enough: displayName, cn, mail, eduPersonAffiliation, eduPersonScopedAffiliation, eduPersonPrincipalName, SAML2 Persistent NameID (eduPersonTargetedID), schacHomeOrganization and schacHomeOrganizationType
>
>> 5.Questions on audits
>>
>> Is it enough for you that a Home Organisation self-asserts that it complies with a certain LoA level?
>
> This heavily depends on the content that needs to be protected. For now self-assertion is enough for most cases.
CLARIN+ should thoroughly inventorize what kind of content protection
classes are appropriate for the current SPF services and resources. As
far as know, otherwise this answer has no solid basis.
>> Should some external body have some enforcement rights (e.g. Home identity federation can remove “compliant” tag from the Home Organisation if there are doubts that a Home Organisation fails its LoA level)?
>
> That would add trust, yes.
>
>> Are internal audits needed?
>> Are external audits needed? Are you willing to share their costs?
>
> To be meaningfully able to self-assert LoA over a longer time period organisations will have to perform internal and external audits.
> The organisation should not only state its LoA level but also how it is maintained. SPs can then filter, if needed.
Seems reasonable. Obviously it remain a difficult issue though. For
instance, what is the assurance level of such a LoA assertion itself?
;) If SPs start filtering on this openly, this kind of far-fetched
question may become relevant as IdPs may try to counter being filtered
out. Not that I think the latter is realistic right now.
> Cheers,
> 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
> _______________________________________________
> Tf-aai mailing list
> Tf-aai at lists.clarin.eu
> https://lists.clarin.eu/cgi-bin/mailman/listinfo/tf-aai
More information about the Tf-aai
mailing list