At the VAMP2013 and FIM4R meeting this week, one of the things we are hearing a lot from the research groups is “we have this specific requirement for our group and identity federations don’t meet it so we can’t use them”. I’m sure that the first part of that statement is true, but I think that rushing to the second part misses out on opportunities for both research collaborations and identity federations – the “collaborative pixie dust’ referred to in one of our presentations.
Identity Federations don’t aim to meet the requirements of specific groups, they aim to provide the broadest possible platform to allow access to resources to occur. If some of the requirements expressed by small research groups were introduced at a base level we may end up blocking out the 90% to satisfy the needs of the 10%, which is not a position that we would want to be in. This doesn’t mean that the needs of the 10% should be ignored.
Two of the issues that I heard this week that are seen as problems with identity federations are:
- Federations don’t provide enough assurance that Identity Providers will participate in incident handling events, and even when they do it is difficult to know that this is happening.
- Our service cannot be used unless Identity Providers have agreed to X and federations don’t tell me that this agreement has been reached.
One argument might be that these are both behaviours that members of a specific group have decided to apply to themselves and should be handled at that group level. Again, neither of these issues is specifically related to access or identity management but about controlling behaviour associated with those identities, so are they really issues for identity federations? However, I think it’s interesting to break those two points down.
Incident Handling
One of the focuses of REFEDS at the moment is breaking down barriers for Service Providers wishing to interact with federations. Lack of standardisation in policy documents and federation operator practices has been identified as one of the key problems in this area. Many federations do indeed have policies in place that require all members to participate in incident handling. An example from the UK federation:
The Member must give reasonable assistance to any other Member investigating misuse. In particular, if the Member uses outsourced identity providers, it must cooperate with the identity provider to investigate and take action in respect of such misuse.
This is fine within the context of a single federation, but when a Service Provider and Identity Provider are connecting via eduGAIN, how can you be sure that entity X is obliged to do so by their federation? An obvious solution is to require Identity Providers to have gone through some sort of assurance accreditation and have this declared in their entity metadata – but LOA schemes are not yet ubiquitous in identity federations and more importantly are time-consuming expensive processes to carry out.
REFEDS is currently working on Federation Operator Practises and a specific suggestion that these practises could be encoded in some sort of machine readable way. This was initially suggested as a way by which Federation Operators can assess practise if they want to pull down metadata from eduGAIN for federation X, but there may be mileage in extending usage of this as a more generic tool?
Another form of ‘lightweight’ assurance vetting that federations are starting to use is Entity Categories. Entity Categories are ways in which certain groups of entities can declare certain characteristics about how they behave. Much of this work to date has focused on Service Providers making claims about how they want to use Personally Identifiable Information (PII), but conceptually this could be extended to a variety of use cases where there is enough demand for broad-level statements.
SSO or SLA?
The standard argument relating to this space is that identity federations were supposed to breakdown the need for bi-lateral agreements between organisations and if Identity Providers and Service Providers still need to negotiate terms, what value are federations adding? I think this is a fairly common misunderstanding of what identity federations are trying to achieve. To again quote from the UK federation policy:
The Member acknowledges that membership of the Federation does not itself grant it or its End Users automatic access to the resources of other Members, and that such access is conditional upon each Member agreeing appropriate terms with the relevant Service Provider governing that access. The Federation Operator will not be responsible for, nor have any liability in respect of, the performance or otherwise of those terms and will not be required to resolve any disputes in relation to those terms.
The federation cannot be involved in any issues arising from a breach or terms of use as it is not a party to the terms under which the service may be used and holds no information about how the user is engaging with a resource. The role of the identity federation is to help organisations reach a level of trust in each other that the service is happy to accept assertions made by an Identity Provider about attributes a specific user might have and to reduce the need for users to have multiple accounts in order to engage with services. Beyond that, conditions of use are issues for the parties using and providing the service. This doesn’t mean that helping research collaborations manage these issues is not our problem.
One of the most common uses of research and education Identity Federations is to support access to e-journals and other scholarly communication materials. Access to these resources is dependent on specific characteristics, typically associated with whether an organisation has paid for access and is only providing it to ‘authorised users’. For this to be possible, a bi-lateral agreement has to be in place – for example the model licence used by JISC Collections. Whilst federations can’t be responsible for such agreeements, we can work with the people creating them to ensure their definitions can be adequately expressed via federation technology – so for example how does a definition of an Authorised User map to an eduPersonScopedAffiliation (see section 7.1.2.1)? There may be more specific work we need to do with research collaborations and virtual organisations to help support a similar process in the context of large-scale research projects and hopefully create the magic pixie dust for the use of identity federations for collaborations.