OpenConext is the completely open source version of SURFconext, the identity federation and educational collaboration platform that is used in the Netherlands. OpenConext was designed under the assumption that the platform would be used in a federated environment. This page provides a high level technical overview of federated identity management to make sure that all deployers and developers of the OpenConext platform work from a common understanding of what federation means in the collaboration management context.
Users of web-based services typically find that they must create accounts with the services in order to use them. The more services a user employs, the greater the number of different accounts and passwords he/she has to remember. This typically leads to insecure practices, such as re-using account names and passwords across all services and storing passwords in the browser. It also means that every Service Provider (SP) has to do its own account management.
Federated Identity Management provides a solution to this problem by separating account management from the service itself. Identity Providers (IdPs) act as the source of identity and account information for a user. That information can then be re-used across all services so that a user only has to remember one account name and password and SPs no longer need to spend time on account management.
Of course the SPs and IdPs have to trust each other for this approach to work. Typically this trust is made explicit by signing policies and contracts that describe the requirements and responsibilities of the IdPs and SPs. An Identity Federation is a collection of IdPs and SPs that have agreed to work together and trust each other.
Typical examples of Identity Federations are the federations as operated by National Research and Education Networks (NREN), such as SURFconext by the Dutch NREN, SURFnet. In these federations the IdPs are typically universities, polytechnics and research institutes. In most cases the IdPs already have a form of account (or identity) management in place in the form of Single Sign On (SSO) technologies since their employees and students already need accounts for accessing internal services. Making those identities available for re-use across external SPs requires only a little additional effort in most cases.
Next to the trust, policies and contracts there needs to be agreement on how to communicate (identity information) between IdPs and SPs. Almost all federations currently use the SAML2.0 protocol (Security Assertion Markup Language version 2.0) to achieve this. An overview of a SAML login flow is shown below.
When a user wants to login to a web based service, the SP redirects the user’s browser to an IdP together with a request to authenticate (instead of authenticating the user itself). The user then logs in at the IdP (typically the users’ “home institution”) and the IdP validates the authentication. If the user successfully logs in, the IdP then redirects the user back to the SP, together with an “assertion” that confirms that the user logged in successfully. This assertion often contains additional information (called “attributes”) about the user, such as his/her name, e-mail address and relationship with the institute (employee, student, …). The SP can then grant access based on that conformation and the additional attributes it received with it.
For security reasons the communication between browser, SP and IdP is almost always done over HTTPS, rather than plain HTTP. In addition, the assertion that the SP receives from the IdP after login by the user is signed by the IdP using a private key to ensure the validity and integrity of the assertion. The public key counterpart of that private key is known by the SP based on an out-of-band exchange and is typically one of the things that needs to be configured when setting up an association between an SP and an IdP (as can be seen later in this document). The authentication request from the SP to the IdP can be signed as well, in which case the IdP also needs to know the public key of that SP of course.
The description of the login process of the previous section works if only one SP and one IdP work together. Of course in practice federations consist of (many) more IdPs and SPs. Every SP that a user from a particular IdP can login to has to be configured at the IdP side and every IdP that an SP accepts users (assertions) from has to be configured at the SP side. This setup is called a ‘mesh’ federation (see figure below). When an SP accepts logins from more than one IdP, it must ask the user where he/she wants to login so it can direct the user to the desired IdP. This selection process is called WAYF (‘Where Are You From’).
The (technical) description of either an IdP or an SP, needed for configuring that entity at the other side, is called metadata. This metadata contains information such as the entity’s name, technical and support contact, technical configuration and the public key of the entity. The role of the federation operator (not shown in this figure) is to collect and verify the metadata of all the IdPs and SPs in a federation (and typically to sign it as well to ensure integrity). By making this combined metadata available at one point to all IdP and SPs, configuring the different IdPs and SPs becomes much easier. An SP or IdP only has to consult the federation metadata to configure a connection to another IdP or SP.
Another approach for setting up a complete federation with multiple IdPs and SPs is to create a proxy in between (see figure below). This is the approach taken by OpenConext. The benefit here is that IdPs and SPs only have to configure one SP and IdP respectively (the proxy). In essence, from the viewpoint of the IdPs the proxy acts as an SP, and from the viewpoint of an SP the proxy acts as an IdP. The proxy relays the requests (shown in the login flow) between the two.
Since the SPs now connect to one IdP (the proxy), they do not have to provide WAYF functionality either; the central proxy can provide the WAYF function for all the SPs (with the benefit of a consistent WAYF, rather than different implementations by the different SPs).
A federation with a central proxy approach (instead of a mesh) is called a ‘hub & spoke’ federation.
OpenConext not only acts as a proxy in a federation, but can also provide centralised group management (that is: manage group information that can be (re)used in all the SPs that are part of a federation. However, group management is not the topic of this guide. For more information regarding OpenConext and its features, please refer to the documentation section on this site.