 |
|
Services | Backbone operation | Technologies | R&D | Networks | Qualification | Events |
 | Authentication infrastructure and federated authorization An authentication infrastructure and federated authorization is made up of two main types of elements:
A basic concept concerning a federation is the trustworthy relationship between service providers and identity providers. The first have to believe in the quality of data provided by identity providers. On the other hand, these have to rely on service providers, ensuring that users use the data only for the purposes agreed. Another aspect of the architecture of a federation is the information management on the identity and service providers by maintaining metadata. The CAFe’s operation keeps data on each of the participating institutions available to participants (address of the server that acts as the identity provider, server certificate, etc.). Support for federated authentication takes place as follows: to access a particular service provider, the user is redirected to a page that gives him a list of identity providers. The user then selects his origin institution and his browser is redirected to the identity provider of that institution. After authenticating the user, the identity provider passes the result of such authentication to the service provider and creates a session of use associated with the user, so that accesses to new services within a given time interval do not generate new authentication requests (single sign-on). Besides the guarantee of authentication, the service provider may request the identity provider information (attributes) about the user, for example, its link with the institution. These attributes can be used to establish user authorization with respect to the resource or service accessed. The privacy setting adopted by the identity provider specifies which users’ attributes may be required by service providers. Information Flow The following figure illustrates the interactions conducted during a typical access via browser, to a federated service. The presented flow assumes that no information about the user is known by the service provider, and this is the first user’s access to a federated service.
1. The user directs his browser at the desired service. 2. The server redirects the browser to the federation discovery service (WAYF). 3. The discovery service presents the user the institutions that offer identity providers for the federation. 4. The user selects an institution and its browser sends to the discovery service data regarding such selection. 5. The discovery service redirects the browser to the institution selected. 6. The institution’s identity provider sends to the browser the user authentication page. 7. The user provides its credentials and the browser sends them to the identity provider. 8. The identity provider generates and sends a handle to the browser, which forwards it to the service provider, which obtains the user’s proof authentication. For some applications this is sufficient to authorize the user’s access to the service. 9. Optionally, the service provider can send an attribute request to the identity/attributes provider using the handle to specify the user in question. 10. The attributes/identity provider returns the values of the attributes required. Adopted technology: SAML and Shibboleth Currently, the SAML protocol (Security Assertion Markup Language) has established itself as an ad hoc standard for exchanging authentication and authorization information between identity and service providers, and it is universally adopted by various academic identity federations. Among the technologies based on SAML, the Shibboleth package, developed within the Internet2 project, has been the most widely used. This is the technology adopted for the CAFe. Data Schema A federation must specify which users’ attributes should be maintained by the identity providers and, if so permitted by its privacy settings, provided to service providers. For the CAFe, the data schema brEduPerson meets this requirement. |
