A Peer-to-Peer Federated Authentication System

Myong H. Kang and Amitabh Khashnobish

Naval Research Laboratory Information Technology Division

4555 Overlook Ave. Washington DC 20375 myong.kang@nrl.navy.mil

Abstract

A Federated identity management system extends identity information across multiple security domains. It is an enabler for sharing information and services among organizations while respecting the authorization decisions of each organization. Federation can be realized in two ways: 1) Conventional federation that is based on a multilateral agreement among participants and 2) Peer-to-peer (P2P) federation that is based on bilateral agreements. In this paper, we introduce a P2P federated authentication system based on the OASIS security assertion markup language (SAML) version 2.0 standard. The P2P federation model is simpler and more flexible than the conventional federation model even though managing peer relationships becomes a burden if the number of peers gets unmanageably large. The conventional federation model and P2P federation model are not mutually exclusive. The two models can co-exist and interoperate.

Key Words – Security, Identity management

1. Introduction

Federated identity management creates globally interoperable identities. It is based on the business agreements, technical agreements, and policy agreements that allow organizations to interoperate based on shared identity management. The goal of identity federation is to enable users of one domain to access resources of another domain seamlessly, and without the need for redundant user administration. Federated identity management builds a secure, trusted environment from multiple organizations, giving users Single Sign On (SSO) and Single Log Out (SLO) capabilities within this circle of trust.

The identity information must be portable from one organization to another, implying both standardized syntaxes by which it can be expressed and standardized protocols by which it can be communicated. The security services technical committee of OASIS consortium has produced an XML-based framework for communicating user authentication, entitlement, and attribute information that can be used for managing federated identity information. OASIS Security Assertion Markup Language (SAML) version 2.0 includes attribute profiles and metadata specifications to improve communication among organizations participating in a federation.

SAML 2.0 [1] provides the foundation for building federated architectures but does not standardize all aspects of federated identity management. SAML addresses one key aspect of identity management: how identity information can be communicated from one domain to another. It is an important building block for federated identity management. SAML does not require user information to be maintained and synchronized among domains. Rather, it abstracts the security framework away from particular implementations or architectures.

A complete federated identity management system should address other aspects such as how a federation is formed, how to authenticate, and how the identity from other domain is used to control access to resources. SAML 2.0 profile of XACML [7] partially addresses the latter.

In this paper, we introduce a peer-to-peer (P2P) federated authentication system based on SAML 2.0. This P2P system was developed under the Comprehensive Maritime Awareness Joint Capability Technology Demonstrations in order to support cross-agency and international information-sharing. It is well suited for the applications that are based on the P2P model such as OurGrid [4] or a situation where bilateral agreements are prevalent. The rest of the paper is

2009 Sixth International Conference on Information Technology: New Generations

978-0-7695-3596-8 2009

U.S. Government Work Not Protected by U.S. Copyright

DOI 10.1109/ITNG.2009.159

382

2009 Sixth International Conference on Information Technology: New Generations

978-0-7695-3596-8 2009

U.S. Government Work Not Protected by U.S. Copyright

DOI 10.1109/ITNG.2009.159

382

organized as follows. Section 2 contrasts conventional federation model and P2P federation model. A P2P federated identity management (FIM) system that was developed by Naval Research Laboratory (NRL) is introduced in section 3. Section 4 analyzes the security posture of the NRL FIM. We conclude the paper in section 5.

2. Conventional Federation vs. Peer-to-Peer

Federation

There are two typical types of agreements to form a trust relationship: multilateral agreement and bilateral agreement. As long as all partners agree on the principles of cooperation, multilateral agreement may save some management overhead. However, in some cases, agreeing on principles of cooperation may not be easy to achieve among all partners. In such case, bilateral agreements can be used. For example, if organizations A, X, Y and Z work together, share resources and all parties agree on the principle of sharing, a multilateral agreement can be achieved. However, if organization A works with organizations X, Y and Z, but, there are no working agreements among organizations X, Y and Z then a multilateral agreement cannot be established. Rather, organization A can establish bilateral relationships with organizations X, Y and Z separately.

Correspondingly, there are two typical types of federated authentication systems: a conventional federated system that is based on a multilateral agreement and a P2P federated system that is based on bilateral agreements. An example of P2P federated systems is shown in figure 1 where organization A has bilateral agreements with organizations X, Y and Z separately.

Figure 1: An example P2P federation.

The conventional federation model and the P2P federation model are not mutually exclusive. We can consider a bilateral relationship as a small federation in the conventional federation model. Also either a peer can join a conventional federation as a member or a conventional federation can be configured a peer in the P2P federation model. Therefore, the two models can co-exist and interoperate.

It is up to the designer of the system to choose the right model. The enterprise applications work smoothly and will be easy to maintain by choosing the right model and identity management system.

3. NRL Federated Identity Management

NRL has developed a federated identity management (FIM) system based on the P2P federation model. It uses OpenSAML 2.0 for generating SAML 2.0 compliant statements. Unlike the conventional federation model that typically requires a multilateral agreement and membership (e.g., InCommon [5]), the P2P federation model does not require a membership to a federation, thus it is a little simpler and more flexible than the conventional federation model. There are pros and cons for each model. Therefore it is important to choose the right model that is well suited for user’s operating environment.

If there are too many peers in a P2P model, managing peers becomes a burden. In our case, the peer is a federation server (see figure 1 and 2) of an organization. One federation server can serve multiple service providers. Since NRL FIM is based on bilateral relationships, every relationship may have different flavors in terms of the attributes that need to be exchanged and the resources that can be accessed.

NRL FIM is built based on the assumption that each domain has its own set of user attributes that are known to its service providers. Thus, its service providers make authorization decision based on this known set of attributes. This allows services to decouple their authorization decisions from any future bilateral agreements. NRL FIM also assumes that not every partner will have the same set of user attributes. Thus, it is every partner’s responsibility to send the correct attributes. NRL FIM provides a simple name mapping and translation facility to accommodate this need (see section 3.2).

NRL FIM consists of three components: federated authentication module (FAM), federation server (FS),

383383

and Authentication & Attributes Gateway (AAG). The federation server has both client side functionality and server side functionality. Therefore, if an organization provides services and also acts as client organization to the services from other organization, only one federation server is needed. In the same way, the same FS can serve local users and remote users (see figure 1) at the same time. Service provider side requires FAM and FS (see figure 2). The function of each individual component will be described in the following subsections.

Figure 2: Service provider side components of NRL FIM.

Client (identity provider) side requires FS and AAG

(see figure 3). The AAG interacts with a domain server (e.g., Active Directory) or any other identity provider (e.g., MySQL) to retrieve user identity and attributes. If a user is a Windows domain user, the AAG will retrieve the login information directly from the domain server using the user’s saved credentials, so that the user does not have to manually provide additional login information for accessing remote services. A detailed explanation of each component will be presented below.

Figure 3: Client (Identity provider) side components of NRL FIM.

3.1. Federated Authentication Module (FAM)

FAM is a connector between the Web application and the rest of federated identity management components. Its primary responsibilities are as follows:

• Acts as the gatekeeper of the application to block unauthenticated service requests and notify its domain FS to obtain user information from client domain.

• Once user information comes back from the client domain, it passes the information to the Web application. The authorization scheme of the Web application makes Web access decision based on the user information.

FAM passes a service request to the application as long as the user who initiates the request is a valid user from a trusted partner domain. FAM just passes user attributes that come from user’s domain to the application. These attributes can be used by the application to perform application-specific access control.

Each Web container (e.g., ASP.NET, Tomcat) needs one FAM to communicate with the federation server. For ASP.NET, FAM is configured as an ASP.NET module written in C#. For Tomcat, FAM is configured as a filter written in Java. 3.2. Federation Server (FS)

Federation server is the main entity that participates in a bilateral agreement with a partner federation server. To become trusted partners, first, the two FSs have to exchange certificates that will be used to validate SAML statements. Second, they have to agree on the user attributes they will exchange. One FS can serve as a gateway to federated identity management for many services as shown in figure 4.

Figure 4: An example of one FS serves two service

providers that are Microsoft ASP.NET and Tomcat.

384384

In our implementation, we do not assume that all partners have the same set of attribute names. Therefore, we provide a simple attribute name mapping and translation facility. For example, attribute α from domain 1 may map to attribute β in domain 2. This mapping facility has additional benefit in designing and coding an application. When an application is deployed in the domain, its access control is designed based on a set of attributes that are known to its own domain. If any future trusted partner has an attribute that is not in the set of known attribute list of the domain, applications are not affected because FS provides attribute mapping capability. The federation server maintains the list of attributes that are being used in its domain and the attribute mapping information with all partners.

The primary responsibilities of FS are as follows: • Keep track of trusted partners by exchanging

certificates with partner FSs. • Maintain the global list of attributes that its own

services use for access control decision. • Maintain attribute mapping information for each

partner and translate attribute names before it sends them out to partners.

• Keep track of its own service providers in the same domain by exchanging certificates with FAMs if FS is in relying party (i.e., server side).

• Validate assertions from other FS and relay the information to FAM if FS is in relying party (i.e., server side).

• Communicate with its own domain AAG to generate SAML 2.0 compliant statements (e.g., authentication assertions) if FS is in asserting party (i.e., client side).

FS is implemented in Java and makes use of

OpenSAML 2.0 library to generate SAML 2.0 compliant statements.

Since FS has to keep track of lots of information and establish connectivity with many partners, we have provided a GUI-based FS administration tool (figure 5) to ease the burden of managing partners and its bilateral contracts.

The tool provides an easy way to • Keep track of trusted partners, service providers,

AAG, and attribute mapping information. It shows: o The URLs and certificates of partners,

service providers and its AAG.

o The list of attribute names of its own domain.

o The list of attributes that are needed by each service.

o Attributes mapping information per partner. o The list of attributes that are expected from

a specific partner. • Upload the certificates of the partners, service

providers and AAG. • Provides a way to perform live connectivity test

by an administrator to ensure the configuration information about the partners are valid. It tests not only physical connectivity but also certificates and attributes information exchange.

Figure 5: Federation server administration tool

3.3. Authentication & Attribute Gateway (AAG)

Each client (Identity provider) domain needs an AAG. The primary responsibilities of this component are as follows:

• Communicate with the domain controller (or other identity provider) to authenticate the user and relay the information about the user to its FS. FS generates a proper SAML authentication statement based on this information.

• Retrieve user attributes from the domain controller or from other attribute store, and pass them to its domain FS to generate a proper SAML attribute statement.

Sometimes, the above two tasks are combined as a one-step process.

385385

We have implemented two types of AAGs: One for Windows domain clients and the other for non-Windows domain clients. For Windows domain clients, the AAG is implemented in C#. Since the client domain already has an Active Directory (AD) as its domain controller, the AAG can validate the user by asking AD. If the user is a valid domain user then the AAG will obtain necessary user attributes from AD. This capability will provide a true single sign on experience from user’s perspective. Since the user has already logged on to its domain controller, no additional log-on is required to access the services in either its own domain or other partner domains.

Active Directory has a static schema. Even though the schema can be extended, it may not be practical to extend the schema of the operational AD because the process may be intrusive to the organization’s other operations. Therefore, AD may not be the ideal place to store all user attributes in some cases. Therefore, NRL FIM uses MySQL to store extra attributes that are needed for the federated identity management.

For non-Windows domain clients, the AAG has to be customized based on the authentication system of the organization. We provide a default non-Windows domain AAG where user information is stored in a MySQL database.

3.4. Interaction among various NRL FIM components

It is instructive to trace a user request and observe the interaction among NRL FIM components. Figure 5 shows an example interaction between a user in a client domain and the service provider in a server domain. If a client domain is also the server domain (i.e., local user), the federation servers in figure 6 are the same federation server.

The interaction starts from a user request.

1. A user from a client (identity provider) domain tries to access a Web service.

2. FAM intercepts the request and detects that the request is from a new user/browser from a partner domain. It then sends the request to the FS of the service provider domain.

3. The FS in the service provider domain determines the client’s domain and sends a

SAML authentication request (AuthnRequest in SAML 2.0 terms) to the FS of the client domain.

4. The client FS sends the authentication request to the AAG.

5. If the user is not a domain user, it will ask user to identify itself (if the user already login to the Windows domain, this step is not needed).

6. The AAG validates user login to the domain controller or other identity provider, and retrieve necessary attributes.

7. If additional attributes are necessary, the AAG retrieves them from the extra attribute store (MySQL in our case).

8. The AAG returns user validation and attributes to FS in its domain.

9. The FS in the client domain sends the response that contains SAML assertions to the FS in the service provider domain. Also FS sends necessary attributes to the FS in the service provider domain. If attribute translation (based on attribute mapping information) is needed then it translates the attributes before FS sends them.

10. User attributes are sent to FAM. 11. Once the user is validated from the trusted client

domain, FAM passes the user attributes to Web application and allows the original request to proceed. The Web application makes access control decision. If the user has the right privileges then the user receives a response from the Web application.

Figure 6: A sample interaction between various components of NRL FIM

386386

4. Security of NRL Federated Identity Management

Thomas Groß analyzed security aspects of SAML 1.0 specification. The OASIS Security Services Technical Committee (SSTC) responded [3] to the paper. SSTC has incorporated some changes to SAML 2.0 in respond to Groß’s paper. The important conclusion is that SAML 2.0 protocol in conjunction with SSL/TLS provides an effective countermeasure to the attacks identified by Groß in [2]. Figure 6 shows SSL traffic that implements the SAML Web browser profile assuming that the Web application supports SSL.

Figure 6: NRL FIM’s SSL traffic in SAML Web browser profile assuming the Web application supports SSL

NRL FIM implementation requires a certificate by

every NRL FIM component to identify itself and sign the messages. Since two communicating parties perform bilateral authentication, the man-in-the-middle attack identified in [2] is almost impossible. Also all traffics between components are SSL/TSL traffics. Thus, integrity and confidentiality of the messages are preserved. Therefore, NRL FIM implemented effective countermeasures to the attacks identified by Groß.

5. Conclusion

In this paper, we have introduced NRL federated identity management system that is based on the P2P federation model. The P2P model fits very well with many military operational environments where bilateral agreements are norm (e.g., agreements with coalition partners). The conventional federation model and P2P

federation model are not mutually exclusive. The two models can co-exist and interoperate. NRL FIM is interoperable with Shibboleth® v2.0 client [6]. In other words, if the client is Shibboleth client, NRL FIM will accept SAML assertion from Shibboleth client and process the assertion just like that from any other partner.

Since the applications use the user attributes from identity management system to make authorization decision, the federated identity management system should be well integrated with the applications. We have used NRL FIM to authenticate users from various organizations for Comprehensive Maritime Awareness (CMA) program. The CMA security architecture and the integration with NRL FIM are presented in [8].

6. References

[1] OASIS Security Services Task Committee, "Security Assertion Markup Language (SAML) 2.0 Technical Overview,” http://www.oasis-open.org/committees/download.php/12938/sstc-saml-tech-overview-2.0-draft-10.pdf, 2005.

[2] Thomas Groß, “ Security Analysis of the SAML Single Sign-on Browser/Artifact Profile,” 19th Annual Computer Security Applications Conference, Las Vegas, December 2003.

[3] OASIS Security Services Task Committee, “Response to ‘Security Analysis of the SAML Single Sign-on Browser/Artifact Profile’,” http://www.oasis-open.org/committees/download.php/13639/sstc-gross-sec-analysis-response-cd-01.pdf Draft 01, 15 July 2005.

[4] A Detsch, L P Gaspary, M P Barcellos, G G H Cavalheiro, “Towards a flexible security framework for P2P based grid computing,” Proceedings of the 2nd workshop on Middleware for grid computing, 2004. Also http://www.ourgrid.org/

[5] InCommon, http://www.incommonfederation.org/ [6] Shibboleth® 2.0, http://shibboleth.internet2.edu/ [7] OASIS, “SAML 2.0 profile of XACML,”

http://docs.oasis-open.org/xacml/access_control-xacml-2.0-saml_profile-spec-cd-02.pdf

[8] M. Kang, et. el., “Overview of the Security architecture of Comprehensive Maritime Awareness System,” Draft paper.

387387