SWITCHaai has a long and successful history in enabling access to hundreds of mainly academic web resources by reusing the authentication mechanisms at the heart of participating organisations.
When joining the SWITCHaai team a couple of years ago, I noticed two things about trust: a) it was just there, and b) no one talked about it. “Trust is established when no one talks about it anymore” someone said. It made me wonder how such a unique construction could be there and just work. There must have been many detailed questions that had to be resolved to get to that point! My curiosity was piqued, so, I started delving into this fascinating topic. How come all of these many service providers, identity providers, end users, organisations and federation partners, commercial or not, just do what the others would expect from them and don’t break trust?
Let’s start with an overview of the roles within an identity federation and their particular expectations towards each other and the federation as a whole.
End users
When you as an end user log in to some service through federated authentication, you want to be sure in particular that
- You are actually seeing the service you want to connect to and you are actually typing in the correct credentials in the right place i.e. you are not accidentally leaking credentials to wrong services
- The service doesn’t abuse the data that it gets about you via federated login e.g. to spam you or sell your details.
- The login process is secure in the sense that your personal data that is sent through the wire cannot be abused by third parties, e.g. by a man-in-the-middle attack to steal and reuse your identity.
While the role of the end user is the most fundamental one, an identity management (IdM) federation can’t do without at least two more important roles, the service provider (SP) and the identity provider (IdP). Let’s have a look at the typical and most important expectations from a SP and an IdP point of view, respectively.
Services
Operators of services (SPs) need to be sure that
- The individuals logging in are actually entitled to do so
- The person logging in can be identified if necessary, directly or through the federation e.g. in case of accidental or deliberate abuse.
Identity providers
(I) Finally, IdPs want to be sure that
- Credentials don’t leak, thus threatening other federated services.
- They can keep their own policies and processes (e.g. for password changes) to ensure compliance with local policy
- Services are bound to use end user data only for the agreed purpose, to ensure obligations under data protection legislation and other processes are met.
How can these diverse expectations be met? Would each of the actors lose control of policy and process to other parties or have to adopt many additional policies in order to use all services? Well, in SWITCHaai it turns out that everyone can see that the advantages outweigh the obligations for each of the roles in a federation context, leading to a landscape where almost all academic institutions in Switzerland opened their IdMs to the federation, and where more than 800 web resources are accessible. Why is this?
The federation can be successful when each of the roles involved gains from it.
Would the federation participant like to be informed about newly joining members? And what if there are really many participants joining all the time? Would this cause a lot of administration? Luckily not, as when a federation defines trustworthy policies and processes for joining, a lot of checking can be avoided. Within SWITCHaai, all parties have to agree to fulfil their duties as set out in shared agreements, with the SWITCHaai Service Description being the common basis for all of them. Following this trust model, newly arriving IdPs are approved by the SWITCHaai team, while newly arriving services are being approved by the resource registration authority administrators at the participating organisations. This process ensures that many of the expectations above are met, e.g. an SP operator can be sure that the IdP operator MUST identify its end users (p. 14) and that the end users are responsible and liable for the misuse of their digital identity towards the IdP operator, the SP operator and SWITCH (p. 15).
Other expectations can be met simply by deploying appropriate technical means such as a federation metadata management tool. The operation of such a system in the federation makes sure that up to date metadata about all participating services and identity providers gets regularly distributed to all of the participating servers. Such metadata usually contains protocol specific details, public keys, contact addresses etc. about all the participating systems. Public keys for SPs and IdPs allow for the verification that end users are actually sent to the right systems when logging in. Moreover, using public key cryptology, user data can be signed and encrypted before being sent to other participants. Finally, if a participating service or identity provider be removed from the federation for some reason, the distributed metadata is updated within hours, which again would in turn result in a full stop of the interoperability with the rest of the federation. Noticing and negotiating this on a bilateral basis could easily take weeks. Luckily, because of the clearly established trust mechanisms, this scenario hasn’t been needed for a long time.
So most of the potential sources for conflicts are addressed within SWITCHaai, be it on the technical or on the contractual side. Still, some detailed or complex trust questions may pop up from time to time, depending on the direction in which a federation develops. One of the topics recently discussed is the direct participation of commercial companies in identity federations, usually in the role of federation partners. While these services can be useful on one hand, end users and the people responsible for running IdPs are often uncertain of their motivations regarding the use of end user data. Within SWITCHaai, this situation is mitigated in two ways:
- The service adopts the principle of requesting the minimum set of attributes as needed for the purpose of authorisation, ideally by agreeing upfront to request only a targeted ID, and refraining from seeking other end user data from the IdP. The end user has thus the chance to remain anonymous from the service, at least as long as the terms of use are respected. It is possible after login that the service will ask the end user for more data directly. Neither the federation nor the IdP can be made responsible in such a case, as this would happen directly between the service and the end user, after the login process has succeeded.
- A user consent module on the IdP ensures that end users are explicitly asked for their consent before their personal data is transferred to the service. This mechanism works perfectly for adults being able to decide for themselves and reduces the likelihood of a service requesting additional information after login. However, in the case of primary/secondary education specific processes may have to be developed e.g. involving consent of the parents, be it upfront or on the fly. This needs to be a consideration for future service development.
We have outlined some of the major expectations of participants in identity federations and what means are put in place within a federation in order to ensure they are met. We have learned that it pays off
- for end users as they get a nationwide SSO in a specific sector only,
- for services as they can easily be set up such that a large user base can access them and they know something about their users they would not otherwise (e.g. the affiliation to a certain organisation)
- for the organisations running the IdPs (we call them Home organisations) as they may easily use shared services with little to no overhead.
Now, how are these participating SPs and IdPs set up so that they can all automatically interact with each other? Each of the SPs needs to know in advance which IdPs are members of a federation and vice versa. How is this trust established technically? Each of these participants generates a private and a public key, using standard PKI tools, and forwards its public key through the metadata distribution mechanism to the other participants. With this mechanism in place, any information originating from such a source could easily be digitally signed, and the signature could easily be verified on the other end. This is exactly what the metadata feed is for. Every participating service or IdP has to deliver some data about itself to the federation, and gets in turn the appropriate data from the others. Well, in the end there’s more to it than just the public keys – there’s also the policy elements of trust. But the public keys are a major part of this metadata file and critical for technical trust.
So we have end users, services, and home organisations providing identities. There’s still one important role that has been left out so far. We have seen that there are various tasks and duties required to act as the glue between IdPs, SPs and users. The role taking care of these aspects is the “federation operator”. A federation operator is responsible for establishing trust, in particular by
- compiling and distributing a common legal framework and policies binding all participants,
- defining and controlling the joining procedure for institutions and their respective services and IdPs, and keeping the signed contracts
- setting up and running an organisational structure which enables responsibility and control to be taken by the participating organisations
- providing on the technical level a “trust anchor” used to validate and signal participation in the federation by SPs and IdPs
- making sure that the participating entities (ie. IdPs and SPs) know of each other in a timely and automated manner
The federation operator’s task contains of course more items, but we only mention the ones with a direct relationship to the establishment of trust within a federation.
When talking to my colleagues here at SWITCH, I learned that the solutions to all those aspects didn’t quite fall into their lap. Each of the aspects discussed above had to be closely analysed and then appropriate solutions had to be developed and evolved during the past ten years or more. Today, we at SWITCH believe the components that are put in place do indeed answer the requirements. SWITCHaai is a trustworthy and trusted service, not only because end user experience says that it “just works”, but also because trust is built in by design. Still, the world is moving and further requirements pop up or existing ones change. We therefore expect to be kept busy in finding new solutions for future challenges, be they related to technology, processes, or to policy aspects.