[Tf-aai] LoA Questionaire

[Jozef Misutka]

Dear Martin and all,

thank you for sharing an indeed interesting survey and for taking the time
to prepare your answers.
I think the first question is whether you plan on answering on behalf of
your CLARIN SP or on behalf of the whole CLARIN. Assuming the latter and
because we do not have CLARIN AAI requirements yet (this is one of the
CLARIN+ subtasks that I will discuss with this TF next week) it is my
belief that we cannot answer some of the very specific questions straight
away.




On 17 September 2015 at 13:32, Martin Matthiesen <martin.matthiesen at csc.fi>
wrote:

> Hi Sander,
>
> Thanks for your comments, the interview is next week and this is an
> attempt to get answers on a broader basis. It is by the way not a closed
> one, I am sure I can arrange for one or two to join in.
> I'll answer below (knowing that email is not the greatest tool here, let's
> maybe set up a meeting, if this thread grows quickly). I kept all text for
> context.
>
> ----- Original Message -----
> > From: "Sander Maijers" <sander at clarin.eu>
> > To: "Martin" <martin.matthiesen at csc.fi>
> > Cc: "tf-aai" <tf-aai at lists.clarin.eu>
> > Sent: Thursday, 17 September, 2015 11:51:21
> > Subject: Re: [Tf-aai] LoA Questionaire
>
> > 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,
>
> I hope to be able to substantiate below.
>
> > which is I think critical if we want to more or less ‘petition’ for
> > any policy changes on the identity federation/IdP side.
>
> In General I feel LoA is on a different planet


I feel the same way.


> when we still are fighting to get some/any attributes in the first place.
> HZSK is still fighting to get an IdP up. But this issue is certainly
> relevant the further AAI goes along.
>
> > 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.
>

I would be cautious here. DSA is in a way a certificate of quality and
conformance to "standard" processes but self assertion that can authorise
you to do something in our SPs you would not be able to do otherwise might
put more responsibility on the SP?! Nevertheless, I think we agree on the
basic fact that the traceability to a real person cannot be self asserted
and that the "well known" attributes should not be self asserted as well.
I suggest we ask the CLARIN legal committee about the whole federation
setup and the legal implications (Does Mikael know the legal details of a
federation in Finland? Is there any chance of winning if you sue a
"misbehaving" user? Any case studies?).




> >>
> >> 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’.
>
> Thanks for that, a clear "yes" it is. I was not quite aware about the user
> base at the Clarin IdP.
>
> >
> >>
> >>>     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)?
>

I think it would be difficult to prove to an IdP operator that a user
misbehaved - would some logs be enough to ban a user? I guess most of the
IdPs do not have any standard processes how to deal with this kind of
situation anyway.

(If Attribute Authority is used we could ban a user with eppn on a project
level with minor configuration/coding.)


>
> I am not aware of any case either. But I do know that abuse can and will
> happen the more interesting material there is on offer. Case in point:
> This material is available for EPA=faculty to all of Clarin (text behind
> the link is in English):
> https://www.csc.fi/-/suomi24-keskustelut-avattiin-yhteiskunnalliseen-tutkimuskayttoon
> and also via simple application in https://lbr.csc.fi. The "Suomi24"
> discussion portal sells the same data to companies. Already for that single
> instance I could not personally claim that being able to block misbehaving
> users from my SP is "not so important". Also, as far as I understand the
> Data Seal of Approval process, good behaviour of users is required, so SPs
> must be able to deal with digressions.
>
> >
> >>>
> >>>     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)?
>
> Recycling of old ePPNs does not happen to my knowledge, but it is possible
> as far as I know the definitions.
>

I have heard from several sources that it has already happened. From random
discussions it seems that it is happening from time to time (how many home
organisations do have a shadow synchronised copy of their IdP user
database?).
There are no statistics so you have to assume it is happening because it is
allowed.


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

The problem is that people (e.g., federation operators) often do not know
that eppn can be reassigned. AA and virtual organisations ignore this fact
completely.
I think that we can ask for phasing out and many people would agree.
However, I am afraid that this still does not imply it would be of any good.


>
> This is based on my own services which heavily rely on ePPN and I
> understand Lindat uses ePPN too.


We are safe from these type of problems because we use {eppn,eptid} +
email. Email is mandatory. If our repository does not receive your email in
the attributes, it will ask for it and verify it by sending an email with a
token you have to click on.



> I believe that the role of Attibute Authorities (like lbr.csc.fi) will
> grow in the future, increasing the need for unique ePPNs.
>
> >>
> >>>     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.
>
> Yes, me too. Here I dared to claim that it is nevertheless good enough for
> Clarin as a whole for now, if it is good enough for the Universities' own
> Identity Management.
>

Nice point.



>
> > 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 agree but I think that in the next few years there are no other solutions
that could be widely deployed to many home organisations.


> >
> > I believe this is a topic that merits investigation under the banner of
> CLARIN+.
>
> I agree, are there such plans?
>

Not at the moment.


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

Agree, I do not see a way how to use this information.


> I would argue that IdPs could state in their metadata: Password complexity
> rules are in place: yes/no.
> "yes" means they have thought about it and a (possibly weak) policy in
> place. I would stop there and only go further if IdPs that say "yes" have
> constant problems with identity theft.
>
> >
> >>>     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)?
>
> To my knowledge no depositor has ever asked for it. I would also argue
> that Language Resource protection is relatively low in the food chain if
> you consider that students mananage their studies, library activities, etc,
> using the same credentials (eg.
> https://wiki.oulu.fi/display/ok2/Optima+Learning+Environment). But this
> might very well change if material on offer via AAI becomes more sensitive.
> I am not aware of such a case, though.
>

I would rephrase it to
CLARIN has not received any requirement for supporting 2 factor
authentication.



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

Seems reasonable and I would leave it as it is but for example Saarland
University had problems with this kind of requirements by DFN and they are
not part of DFN anymore.
If I remember correctly, it was related to alumni and their accounts.



> >>
> >>
> >>>
> >>> 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?)
>
> I meant that a user self-asserts, say his phone number, but signs for the
> data to be correct during registration at the university. As opposed to
> changing data at will via a web form.
>


I am not sure we should claim anything about self assertions.


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

The results could be drawn from the survey we conducted couple of months
ago.
https://docs.google.com/spreadsheets/d/17THRllM2VKuV-NDivSoJZmUDpmtAJM-nOMihnPv74JU/edit#gid=1619541889


>
> I based my answer on the fact that LoA rarely comes up in discussion. And
> I assume that this is due to the fact that (detected) abuse is rare. And
> after all, most of our user base come from academic institutions where we
> even now assume that those institutions know what they are doing in terms
> of user registration. Even without self-assertion.
>

If the self assertion is enough (like with CoCo) to put the burden on the
IdP shoulders I agree. Otherwise, we should not answer this question.


>
> >>>     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?
> > ;)
>
> Yes you can play this game ad infinitum. And that is my personal reason
> for not over-emphasizing audits and certificates and the rest of it, even
> though they might be helpful. The DSA-process is largely peer-reviewed
> self-assertion and I found it very helpful for us. But take a few ISO
> 9000/1 examples for your entertainment:
> http://qualitymanagementsystem.com/total-quality-management/the-greatest-quality-management-system-failures-in-history


I cannot even imagine how long would audits of several thousands IdPs
take...


>
>
> > 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.
>
> Yes. And filtering out does not need to be black and white. If I have a
> user from a lower LoA-IdP I can always try to use alternative ways of
> making sure he is who he claims to be, if the protected resource so demands.
>
> Cheers,
> Martin
> _______________________________________________
> Tf-aai mailing list
> Tf-aai at lists.clarin.eu
> https://lists.clarin.eu/cgi-bin/mailman/listinfo/tf-aai
>

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