University of Murcia
DAMe Project
June 2007
Table of
Contents
Introduction
Analysis of the requirements
Architectural overview
User
Protected Service
Home Institution
Remote Institution
Access Point (AP)
RADIUS server from Remote Institution
RADIUS server from Home Institution
eduGAIN BE from Remote Institution
eduGAIN BE from Home Institution
eduGAIN Metadata Service (MDS)
Identity Provider
Protocols and profiles
Network authentication
Token delivery
Resource access using SSO
Security and privacy considerations
References
Introduction
In the last years, we have experienced the emergence of federated approaches to resource sharing. In this approaches, trust links are established among different autonomous organizations in order to grant users in any of them access to shared resources with a single identity, stated by the organization the user belongs to. Important examples of these approaches are the establishment of academic federations worldwide, like eduroam, InCommon, HAKA or SWITCH. In those scenarios where users are moving among the different organizations pertaining to the federation, authorized users may also have additional resources at their disposal at the visited institutions.
Despite many aspects of federations have been addressed by several projects, other issues generally related with integral identity management are still open. For example, in those scenarios where authentication mechanisms have been included for network access control purposes, it would be interesting to create a seamless link between the network-layer authentication mechanism and any additional authentication step that will be needed when users try to gain access to application-level resources. This would involve the extension of the network access mechanism in order to deliver additional information (some kind of security credentials) that might be used at service-level in order to avoid further user re-authentication.
The work presented in this paper is one of the objectives defined by the DAMe project [1]. Once the eduroam infrastructure has been extended so that user mobility will be controlled by security assertions and policies expressed in standard and extensible languages, such as SAML [3] and XACML [2], the next phase is to provide a global Single Sign On (SSO) mechanism based on that extension. Eduroam constitutes an exceptional starting point in order to provide a mechanism for transmitting the user credentials that will be used by the application-level authorization systems in order to offer a full and integrated network access experience to the users. As we will see, we have defined two different steps in order to achieve the SSO. The first one is related to the delivery of a security token during the network access that will be later used to avoid unnecessary re-authentication. Then, once that token has been transmitted to the user, it will be necessary to define how an application-level service will be able to validate that information using a federation-level service. Specifically, we will follow some guidelines already stated by the technical community in order to provide global SSO.
Analysis of the requirements
The proposal presented here follows the guidelines defined by the uSSO framework [4]. It is centered in a multidomain scenario where different authorization systems are defined to access to the resources. These are the main requirements considered for the SSO:
– The user has the appropriate credentials in its home institution (HI).
– HI belongs to a federation where its issued credentials are valid.
– When the user tries to access to a resource (R) in another institution (RI), the decision about the access is taken by an Authorization Service at the RI.
– The authentication and authorization information about users is exchanged between institutions through a mechanism provided by the confederation.
– There is a confederation-aware component called "Local Federation Adaptor" (LFA) which decides if an authentication request can be handled locally or must be sent to another institution. The functionality related to This LFA is commonly performed by the eduGAIN BE [6].
Considering eduroam, once the user is associated to a wireless access point or is connected to a wired switch in the remote institution, he is requested for authentication information. When provided, those credentials are forwarded to the user home institution to be authenticated. But now, to enable the SSO, an Identity Provider is responsible for authenticating the user instead of the RADIUS server. Besides, this service should return to the user some kind of statement that can be used later to achieve the SSO. It is necessary to take into account that, due to the use of different Identity Providers is possible, an intermediate entity is needed to translate the request and responses into the appropriate formats. At this point, the user is allowed to access to the network.
Lately, he might want to access to a protected resource in this institution or in another one belonging to the same federation. Then the user’s credentials are sent to the resource in order to be validated to gain access. Depending on the type of resource, additional steps for obtaining user attributes would be needed.
This generic pattern presented here is detailed using specific technologies in the next section, where we present the architecture for SSO and the interaction among the different elements.
Architectural overview
The architecture for this proposal, which is shown in Figure 1, starts with the elements needed to authenticate the user using eduroam, that is, the access point with 802.1X [5] support and the hierarchy of RADIUS servers. Moreover, according to the previous section, it is necessary to include new elements to authenticate the user and generate the SSO token. In this proposal, the intermediary element receives authentication requests from the Radius server and translates them into the internal federation language. Later, using the response from the specific Identity Provider, it generates the SSO token that will be understandable in all the confederation. On his part, the Identity Provider can be whatever previously deployed one, such as the Shibboleth IdP or the PAPI AS.
These elements constitute the core of the user authentication phase, but new elements must be defined to allow institutions based on different authorization infrastructures to create a global SSO scenario. This cooperation can be achieved using a confederation management infrastructure such as eduGAIN [6]. Here, the Bridging Elements (BE) from eduGAIN will be responsible for translating the requests and responses from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa. In this way, the previously defined intermediary element can be an eduGAIN BE. Besides, the BE is responsible for finding the corresponding BE from the user home institution by means of queries to the MetaData Service (MDS). In relation to the authorization decisions, attributes are requested through eduGAIN and returned by the Identity Provider. Therefore, the BEs are responsible for translating the attribute requests from the remote institution federation language to eduGAIN and from eduGAIN to the home institution federation language. Finally, once the remote institution obtains the user's attributes, the decision is taken using the authorization engine defined in its federation.
Figure 1: DAMe SSO architecture
User
Is the entity requesting access firstly to the network and later to the protected service. He only authenticates the first time, while the nexts a SSO token must be used.
Protected Service
This service is protected in such a way that before access to it, the user has to present some kind of credential.
Home Institution
This one is the institution where the roaming user firstly access to the networks and later tries to access to some resource. The initial authentication will be forwarded to the home institution but the following accesses to protected resources must be authorized based on the SSO token.
Access Point (AP)
It is the entity providing physical network access to users. The AP must support the 802.1X specification to perform the access control.
RADIUS server from Remote Institution
This server is the authentication element defined in the 802.1X specification. It receives authentication requests from the AP. If the user belongs to this organization the request will be processed locally. Otherwise, if he is a roaming user, the request will be forwarded to the appropriate RADIUS server.
RADIUS server from Home Institution
This authentication server receives authentication requests from the eduroam infrastructure. These requests are from roaming users who belong to this institution. Moreover, as later described, the RADIUS server will be extended to support the delivery of the SSO token.
eduGAIN BE from Remote Institution
This element connects the institution to the confederation. More specifically, this BE is responsible for finding the corresponding
BE from the user home institution by means of queries to the MetaData Service (MDS) and for translating the requests and responses
from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa.
eduGAIN BE from Home Institution
This element connects the institution to the confederation. More specifically, this BE is responsible for translating the requests and responses
from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa.
Besides, this element generates the SSO token based on the authentication credentials generated by the Identity Provider.
eduGAIN Metadata Service (MDS)
The MDS is a central point where federations publish their metadata, such as location or authentication and authorization mechanisms, to allow other federations to discover it, and in this way, enable the inter-federation communications.
Identity Provider
This element is the specific entity in the Home Institution that generates authentication assertions for the roaming users. Later, if it is necessary, this element can provide information about the users belonging to its institution.
Protocols and profiles
Since the interaction among these elements must follow the pattern defined in the previous section, it is necessary to define two different processes. On one hand, we need to authenticate the user in order to access to the network and to receive the SSO credentials or token. On the other hand, protected resources have to use the token to validate the user’s identity.
Network authentication
Once described the architectural elements, the next step is to define the specific protocols implementing the profile depicted in previous sections. First, the system authenticates the user by means of some authentication method, for example PEAP [7] as we will see, and then generates some security data which is returned to him.
In DAMe, this first phase is based on the eduroam authentication through the RADIUS hierarchy (dotted lines in Figure 1), but it is enhanced with the delivery of security data to the user. Specifically, as Figure 2 details, when the user tries to access to the network in the remote institution, the remote RADIUS server forwards the authentication request to the RADIUS server located in the home institution. After authenticate the roaming user, this server asks the BE for the SSO token, which translates and forwards the requests to the Identity Provider (IdP). Based on the response from the IdP, the BE builds the SSO token. The token, which is the data the user receives to enable SSO, is a SAML sentence which contains information about the user’s identity, his credentials and the kind of authentication being performed. To protect the user privacy in the SSO, this statement can contain an opaque handle generated by the IdP. Finally, the remote RADIUS server returns the token to the user through a TLS tunnel created by the authentication method. The creation of that tunnel is detailed in the next section.
Figure 2: Initial authentication
Token delivery
The TLS tunnel mentioned before is part of the PEAPv2 [7] authentication method. The reason to use PEAPv2 to authenticate the user is the need for a protected channel to deliver the SSO statement. Figure 3 shows the sequence of messages needed to authenticate the user using this method. It has the special feature that after an initial handshake creates a protected tunnel between the peer and the authenticator. Then, this tunnel is used to exchange the authentication information in a secure way. Therefore the SSO mechanism can take advantage of this tunnel and use it to deliver the statement to the user in a secure way. Specifically, elements are transmitted through the tunnel by means of Type Length Value (TLV) objects. Besides, there is a special TLV, named vendor specific, which can be used to carry non standard elements. In this way, the authenticator can add the security data inside a vendor specific TLV to the last message sent to the peer before closing the tunnel.
Figure 3: PEAP authentication method and vendor specific TLV
Resource access using SSO
The second phase starts when the user tries to gain access to a protected resource after receiving the SSO token. Due to this data is used as a proof of user’s authentication, it is not necessary to ask the user again for his credentials. In this way, once the user has received the SSO data, he can access to whatever service that supports this SSO mechanism.
The specific process is shown in Figure 4, where the user tries to access to some protected service in the remote institution and the service redirects the user to the BE which is responsible to validate the token. Then, the BE requests the SSO token to the user and checks the signature and time validity of the token. Finally, a response with information about the validity of the token is sent to the service. Based on this information, the service can enable the user access, but optionally, it might impose a fine grain authorization based on more information besides the SSO token validity. In order to do this, the service sends an attribute query to the BE. If the SSO token does not contain this information, the BE queries the eduGAIN MDS service to know how to find the BE belonging to the user’s home institution, and then sends the query to it. When the home institution BE receives the query, it is forwarded to the IdP. This entity firstly validates the handle an recovers the user’s attributes to return to the remote institution. Probably, the attribute format of the different federations will be different, therefore some kind of format conversion will be needed. When the protected service receives the attributes through the BE, it finalizes the authorization process by means of its specific authorization engine
Figure 4: Authentication using the token
Security and privacy considerations
[1] DAMe Project. http://dame.inf.um.es.
[2] A. Anderson et al. EXtensible Access Control Markup Language (XACML) Version 1.0, February 2003. OASIS Standard.
[3] Maler Eve, Mishra Prateek, and Philpott Rob. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)v1.1, September 2003. OASIS Standard.
[4] B. Kerver, M. Stanica, J. Rauschenbach, and K. Wierenga. Deliverable DJ5.3.1: Documentation on GÉANT2 Universal Single Sign-On (uSSO) Requirements, February 2007. GN2 JRA5. Geant 2.
[5] LAN MAN Standards Committee of the IEEE Computer Society. IEEE Draft P802.1X/D11: Standard for Port based Network Access Control, March 2001.
[6] D.R. López, J. Macias, M. Molina, J. Rauschenbach, A. Solberg, and M. Stanica. Deliverable DJ5.2.3.1: Best Practice Guide - AAI Cookbook - First Edition, September 2006. GN2 JRA5. Geant 2.
[7] A. Palekar, D. Simon, J. Salowey, H. Zhou, G. Zorn, and S. Josefsson. Protected EAP Protocol (PEAP) Version 2, October 2004. Internet Draft.
Introduction
Analysis of the requirements
Architectural overview
User
Protected Service
Home Institution
Remote Institution
Access Point (AP)
RADIUS server from Remote Institution
RADIUS server from Home Institution
eduGAIN BE from Remote Institution
eduGAIN BE from Home Institution
eduGAIN Metadata Service (MDS)
Identity Provider
Protocols and profiles
Network authentication
Token delivery
Resource access using SSO
Security and privacy considerations
References
Introduction
In the last years, we have experienced the emergence of federated approaches to resource sharing. In this approaches, trust links are established among different autonomous organizations in order to grant users in any of them access to shared resources with a single identity, stated by the organization the user belongs to. Important examples of these approaches are the establishment of academic federations worldwide, like eduroam, InCommon, HAKA or SWITCH. In those scenarios where users are moving among the different organizations pertaining to the federation, authorized users may also have additional resources at their disposal at the visited institutions.
Despite many aspects of federations have been addressed by several projects, other issues generally related with integral identity management are still open. For example, in those scenarios where authentication mechanisms have been included for network access control purposes, it would be interesting to create a seamless link between the network-layer authentication mechanism and any additional authentication step that will be needed when users try to gain access to application-level resources. This would involve the extension of the network access mechanism in order to deliver additional information (some kind of security credentials) that might be used at service-level in order to avoid further user re-authentication.
The work presented in this paper is one of the objectives defined by the DAMe project [1]. Once the eduroam infrastructure has been extended so that user mobility will be controlled by security assertions and policies expressed in standard and extensible languages, such as SAML [3] and XACML [2], the next phase is to provide a global Single Sign On (SSO) mechanism based on that extension. Eduroam constitutes an exceptional starting point in order to provide a mechanism for transmitting the user credentials that will be used by the application-level authorization systems in order to offer a full and integrated network access experience to the users. As we will see, we have defined two different steps in order to achieve the SSO. The first one is related to the delivery of a security token during the network access that will be later used to avoid unnecessary re-authentication. Then, once that token has been transmitted to the user, it will be necessary to define how an application-level service will be able to validate that information using a federation-level service. Specifically, we will follow some guidelines already stated by the technical community in order to provide global SSO.
Analysis of the requirements
The proposal presented here follows the guidelines defined by the uSSO framework [4]. It is centered in a multidomain scenario where different authorization systems are defined to access to the resources. These are the main requirements considered for the SSO:
– The user has the appropriate credentials in its home institution (HI).
– HI belongs to a federation where its issued credentials are valid.
– When the user tries to access to a resource (R) in another institution (RI), the decision about the access is taken by an Authorization Service at the RI.
– The authentication and authorization information about users is exchanged between institutions through a mechanism provided by the confederation.
– There is a confederation-aware component called "Local Federation Adaptor" (LFA) which decides if an authentication request can be handled locally or must be sent to another institution. The functionality related to This LFA is commonly performed by the eduGAIN BE [6].
Considering eduroam, once the user is associated to a wireless access point or is connected to a wired switch in the remote institution, he is requested for authentication information. When provided, those credentials are forwarded to the user home institution to be authenticated. But now, to enable the SSO, an Identity Provider is responsible for authenticating the user instead of the RADIUS server. Besides, this service should return to the user some kind of statement that can be used later to achieve the SSO. It is necessary to take into account that, due to the use of different Identity Providers is possible, an intermediate entity is needed to translate the request and responses into the appropriate formats. At this point, the user is allowed to access to the network.
Lately, he might want to access to a protected resource in this institution or in another one belonging to the same federation. Then the user’s credentials are sent to the resource in order to be validated to gain access. Depending on the type of resource, additional steps for obtaining user attributes would be needed.
This generic pattern presented here is detailed using specific technologies in the next section, where we present the architecture for SSO and the interaction among the different elements.
Architectural overview
The architecture for this proposal, which is shown in Figure 1, starts with the elements needed to authenticate the user using eduroam, that is, the access point with 802.1X [5] support and the hierarchy of RADIUS servers. Moreover, according to the previous section, it is necessary to include new elements to authenticate the user and generate the SSO token. In this proposal, the intermediary element receives authentication requests from the Radius server and translates them into the internal federation language. Later, using the response from the specific Identity Provider, it generates the SSO token that will be understandable in all the confederation. On his part, the Identity Provider can be whatever previously deployed one, such as the Shibboleth IdP or the PAPI AS.
These elements constitute the core of the user authentication phase, but new elements must be defined to allow institutions based on different authorization infrastructures to create a global SSO scenario. This cooperation can be achieved using a confederation management infrastructure such as eduGAIN [6]. Here, the Bridging Elements (BE) from eduGAIN will be responsible for translating the requests and responses from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa. In this way, the previously defined intermediary element can be an eduGAIN BE. Besides, the BE is responsible for finding the corresponding BE from the user home institution by means of queries to the MetaData Service (MDS). In relation to the authorization decisions, attributes are requested through eduGAIN and returned by the Identity Provider. Therefore, the BEs are responsible for translating the attribute requests from the remote institution federation language to eduGAIN and from eduGAIN to the home institution federation language. Finally, once the remote institution obtains the user's attributes, the decision is taken using the authorization engine defined in its federation.
Figure 1: DAMe SSO architecture
User
Is the entity requesting access firstly to the network and later to the protected service. He only authenticates the first time, while the nexts a SSO token must be used.
Protected Service
This service is protected in such a way that before access to it, the user has to present some kind of credential.
Home Institution
This
one
is the institution where the user belongs to. It is responsible for
defining
the user’s profile and generate the SSO token.
This one is the institution where the roaming user firstly access to the networks and later tries to access to some resource. The initial authentication will be forwarded to the home institution but the following accesses to protected resources must be authorized based on the SSO token.
Access Point (AP)
It is the entity providing physical network access to users. The AP must support the 802.1X specification to perform the access control.
RADIUS server from Remote Institution
This server is the authentication element defined in the 802.1X specification. It receives authentication requests from the AP. If the user belongs to this organization the request will be processed locally. Otherwise, if he is a roaming user, the request will be forwarded to the appropriate RADIUS server.
RADIUS server from Home Institution
This authentication server receives authentication requests from the eduroam infrastructure. These requests are from roaming users who belong to this institution. Moreover, as later described, the RADIUS server will be extended to support the delivery of the SSO token.
eduGAIN BE from Remote Institution
This element connects the institution to the confederation. More specifically, this BE is responsible for finding the corresponding
BE from the user home institution by means of queries to the MetaData Service (MDS) and for translating the requests and responses
from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa.
eduGAIN BE from Home Institution
This element connects the institution to the confederation. More specifically, this BE is responsible for translating the requests and responses
from the specific institution authentication or authorization mechanism to the eduGAIN protocols, and vice versa.
Besides, this element generates the SSO token based on the authentication credentials generated by the Identity Provider.
eduGAIN Metadata Service (MDS)
The MDS is a central point where federations publish their metadata, such as location or authentication and authorization mechanisms, to allow other federations to discover it, and in this way, enable the inter-federation communications.
Identity Provider
This element is the specific entity in the Home Institution that generates authentication assertions for the roaming users. Later, if it is necessary, this element can provide information about the users belonging to its institution.
Protocols and profiles
Since the interaction among these elements must follow the pattern defined in the previous section, it is necessary to define two different processes. On one hand, we need to authenticate the user in order to access to the network and to receive the SSO credentials or token. On the other hand, protected resources have to use the token to validate the user’s identity.
Network authentication
Once described the architectural elements, the next step is to define the specific protocols implementing the profile depicted in previous sections. First, the system authenticates the user by means of some authentication method, for example PEAP [7] as we will see, and then generates some security data which is returned to him.
In DAMe, this first phase is based on the eduroam authentication through the RADIUS hierarchy (dotted lines in Figure 1), but it is enhanced with the delivery of security data to the user. Specifically, as Figure 2 details, when the user tries to access to the network in the remote institution, the remote RADIUS server forwards the authentication request to the RADIUS server located in the home institution. After authenticate the roaming user, this server asks the BE for the SSO token, which translates and forwards the requests to the Identity Provider (IdP). Based on the response from the IdP, the BE builds the SSO token. The token, which is the data the user receives to enable SSO, is a SAML sentence which contains information about the user’s identity, his credentials and the kind of authentication being performed. To protect the user privacy in the SSO, this statement can contain an opaque handle generated by the IdP. Finally, the remote RADIUS server returns the token to the user through a TLS tunnel created by the authentication method. The creation of that tunnel is detailed in the next section.
Figure 2: Initial authentication
Token delivery
The TLS tunnel mentioned before is part of the PEAPv2 [7] authentication method. The reason to use PEAPv2 to authenticate the user is the need for a protected channel to deliver the SSO statement. Figure 3 shows the sequence of messages needed to authenticate the user using this method. It has the special feature that after an initial handshake creates a protected tunnel between the peer and the authenticator. Then, this tunnel is used to exchange the authentication information in a secure way. Therefore the SSO mechanism can take advantage of this tunnel and use it to deliver the statement to the user in a secure way. Specifically, elements are transmitted through the tunnel by means of Type Length Value (TLV) objects. Besides, there is a special TLV, named vendor specific, which can be used to carry non standard elements. In this way, the authenticator can add the security data inside a vendor specific TLV to the last message sent to the peer before closing the tunnel.
Figure 3: PEAP authentication method and vendor specific TLV
Resource access using SSO
The second phase starts when the user tries to gain access to a protected resource after receiving the SSO token. Due to this data is used as a proof of user’s authentication, it is not necessary to ask the user again for his credentials. In this way, once the user has received the SSO data, he can access to whatever service that supports this SSO mechanism.
The specific process is shown in Figure 4, where the user tries to access to some protected service in the remote institution and the service redirects the user to the BE which is responsible to validate the token. Then, the BE requests the SSO token to the user and checks the signature and time validity of the token. Finally, a response with information about the validity of the token is sent to the service. Based on this information, the service can enable the user access, but optionally, it might impose a fine grain authorization based on more information besides the SSO token validity. In order to do this, the service sends an attribute query to the BE. If the SSO token does not contain this information, the BE queries the eduGAIN MDS service to know how to find the BE belonging to the user’s home institution, and then sends the query to it. When the home institution BE receives the query, it is forwarded to the IdP. This entity firstly validates the handle an recovers the user’s attributes to return to the remote institution. Probably, the attribute format of the different federations will be different, therefore some kind of format conversion will be needed. When the protected service receives the attributes through the BE, it finalizes the authorization process by means of its specific authorization engine
Figure 4: Authentication using the token
Security and privacy considerations
The security of this design relies on several elements of the architecture. On one hand, the RADIUS server from the Home Institution must successfully authenticate the user because the overall process is based on this identity, and besides, the SSO token must be delivered to the user in a secure way. On the other hand, the eduGAIN infrastructure must be trusted. That is, the different BEs and the MDS must authenticate each other, and their messages must be protected.
[1] DAMe Project. http://dame.inf.um.es.
[2] A. Anderson et al. EXtensible Access Control Markup Language (XACML) Version 1.0, February 2003. OASIS Standard.
[3] Maler Eve, Mishra Prateek, and Philpott Rob. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML)v1.1, September 2003. OASIS Standard.
[4] B. Kerver, M. Stanica, J. Rauschenbach, and K. Wierenga. Deliverable DJ5.3.1: Documentation on GÉANT2 Universal Single Sign-On (uSSO) Requirements, February 2007. GN2 JRA5. Geant 2.
[5] LAN MAN Standards Committee of the IEEE Computer Society. IEEE Draft P802.1X/D11: Standard for Port based Network Access Control, March 2001.
[6] D.R. López, J. Macias, M. Molina, J. Rauschenbach, A. Solberg, and M. Stanica. Deliverable DJ5.2.3.1: Best Practice Guide - AAI Cookbook - First Edition, September 2006. GN2 JRA5. Geant 2.
[7] A. Palekar, D. Simon, J. Salowey, H. Zhou, G. Zorn, and S. Josefsson. Protected EAP Protocol (PEAP) Version 2, October 2004. Internet Draft.