Design and Implementaion of a Single Sign-On Library Supporting SAML (Security Assertion Markup Language) for Grid and Web Services Security Dongkyoo Shin, Jongil Jeong, and Dongil Shin Department of Computer Science and Engineering, Sejong University 98 Kunja-Dong, Kwangjin-Ku, Seoul 143-747, Korea {shindk, jijeong, dshin}@gce.sejong.ac.kr Abstract. In recent years, the Grid development focus is transitioning from resources to services. A Grid Service is defined as a Web Service that provides a set of well-defined interfaces and follows specific conventions. SAML is an XML based Single sign-on (SSO) standard for Web Services, which enables the exchange of authentication, authorization, and profile information between different entities. This provides interoperability between different security services in distributed environments. In this paper, we designed and implemented Java-based SAML APIs to achieve an SSO library. 1 Introduction Grid computing denotes a distributed computing infrastructure for advanced science and engineering. It supports coordinated resource sharing and problem solving across dynamic and geographically dispersed organizations. Moreover, the sharing concerns not only file exchange but also direct access to computers, software, data, and other resources [1]. In recent years, the Grid development focus is transitioning from resources to services. A Grid Service is defined as a Web Service that provides a set of welldefined interfaces and follows specific conventions [2]. The interfaces address discovery, dynamic service creation, lifetime management, notification and manageability. Web Services [3], proposed by World Wide Web Consortium (W3C), provide a standatd which is designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL - Web Services Description Language). Other systems interact with the Web services in a manner prescribed by its description using SOAP(Simple Object Access Protocol) messages, typically conveyed using HTTP with an XML serialization. Single sign-on (SSO) is a security feature, which allows a user to log into many different services offered by the distributed systems such as Grid [4] and Web Services, while the user only needs to authenticate once, or at least always in the same way [5, 6]. Various SSO solutions have been proposed that depend on public
key infrastructure (PKI), Kerberos, or password-stores, which require an additional infrastructure on the client s side and new administrative steps [7]. Recently a new standard for exchange of security-related information in XML called Security Assertions Markup Language (SAML) [8,9] is recommended by the Organization for Advancement of Structured Information Standards (OASIS). SAML enables the exchange of authentication, authorization, and profile information between different entities to provide interoperability between different security services in distribution environments such as Grid and Web Services. The security information described by SAML is expressed in XML format for assertions, which can be either: authentication assertions, attribute assertions, or authorization decision assertions. SAML authorities issue assertions, which can be security service providers or business organizations. Assertions provide a means of avoiding redundant authentication and access control checks, thereby providing single sign-on functionality across multiple target environments. SAML also defines the protocol by which the service consumer issues the SAML request and SAML authority returns the SAML response with assertions. While SAML is an authentication standard for Web Services, it is also proposed as a message format for requesting and expressing authorization assertions and decisions from an OGSA(Open Grid Services Architecture) authorization service [10]. In this paper, we designed and implemented a Java-based SSO library made up of SAML Application Programming Interfaces (APIs). 2 Background The basic idea of single sign-on (SSO) is to shift the complexity of the security architecture to the SSO service and release other parts of the system from certain security obligations. In the SSO architecture, all security algorithms are found in the single SSO service, which acts as the single and only authentication point for a defined domain. The SSO service acts as the wrapper around the existing security infrastructure that exports various security features like authentication and authorization [5,6]. For SSO implementation, classical three-party authentication protocols that exploit key-exchanges such as Kerberos and Needham-Schroeder are used. Since these protocols start with a key-exchange or key-confirmation phase, the client application uses the new or confirmed key for encryption and authentication [11]. For a different approach for SSO implementation, token-based protocols such as cookies or SAML are used [11]. Being different to key-exchange protocols, an authentication token is sent over an independently established secure channel. In other words, a secure channel is established without an authenticated client key, in which the Secure Socket Layer (SSL) [12] is usually used with browsers, and then an authentication token is sent in this channel without conveying a key. The main advantage of token-based protocols is that a majority of service providers already have SSL server certificates and a suitable cryptographic implementation is available on all client machines via the browsers. In addition, one can use several unrelated
authentication tokens to provide information about the user in the same secure channel with the service provider [11]. SAML is a standard suitable for facilitating site access among trusted security domains after single authentication. Artifacts, which have a role of tokens, are created within a security domain and sent to other security domains for user authentication. Since the artifacts sent to the other domains are returned to the original security domain and removed after user authentication, this resolves the problems of session keys being revealed and stolen tokens in the browser. In addition, artifact destination control is fully achieved since artifact identification is attached to the Uniform Resource Locator (URL) and redirects the message sent to the destination [8]. 2.1 SAML(Security Assertion Markup Language) Recently, OASIS has completed SAML, a standard for exchanging authentication and authorization information between domains. SAML is designed to offer single signon for both automatic and manual interactions between systems. It will let users log into another domain and define all of their permissions, or it will manage automated message exchanges between two parties. SAML is a set of specification documents that define its components: Assertions and request/response protocols Bindings (the SOAP-over-HTTP method of transporting SAML requests and responses) Profiles (for embedding and extracting SAML assertions in a framework or protocol) Security considerations while using SAML Conformance guidelines and a test suite Use cases and requirements <element name= Assertion type= saml:assertiontype /> <complextype name= AssertionType > <sequence> <element ref= saml:conditions minoccurs= 0 /> <element ref= saml:advice minoccurs= 0 /> <choice maxoccurs= unbounded > <element ref= saml:statement /> <element ref= saml:subjectstatement /> <element ref= saml:authenticationstatement /> <element ref= saml:authorizationdecisionstatement /> <element ref= saml:attributestatement /> </choice> <element ref= ds:signature minoccurs= 0 /> </sequence> <attribute name= MajorVersion type= integer use= required /> <attribute name= MinorVersion type= integer use= ruquired /> <attribute name= AssertionID type= saml:idtype use= required /> <attribute name= Issuer type= string use= required /> <attribute name= Issuelnstant type= datetime use= required /> </complextype> <saml:assertion AssertionID= 00cda300-0d5de-8521-83c5- c2d9f6847b91 IssueInstant= 2003-03-24T14:36:56Z Issuer= verisign, Inc. MajorVersion= 1 MinorVersion= 0 > <saml:conditions NotBefore= 2003-03-24T14:36:56Z NotOnOrAfter= 2003-03-24T14:36:56Z /> <saml:authenticationstatement AuthenticationMethod= password AuthenticationInstant= 2003-03-24T14:36:56Z > <saml:subject> <saml:nameidentifier NameQualifier= sejong.ac.kr > jeongjongil </saml:nameidentifier> </saml:subject> </saml:authenticationstatement> </saml:assertion> Fig. 1. Structure of Assertion Schema Fig. 2. Assertion with Authentication Statement
SAML enables the exchange of authentication and authorization information about users, devices or any identifiable entity called subjects. Using a subset of XML, SAML defines the request-response protocol by which systems accept or reject subjects based on assertions [8,9]. An assertion is a declaration of a certain fact about a subject. SAML defines three types of assertions: Authentication: indicating that a subject was authenticated previously by some means (such as a password, hardware token or X.509 public key). Authorization: indicating that a subject should be granted or denied resource access. Attribution: indicating that the subject is associated with attributes. Figure 1 shows an assertion schema and Figure 2 shows the assertion statement, which includes authentication assertion issued by SAML authority. SAML does not specify how much confidence should be placed in an assertion. Local systems decide if security levels and policies of a given application are sufficient to protect an organization if damage results from an authorization decision based on an inaccurate assertion. This characteristic of SAML is likely to spur trust relationships and operational agreements among Web-based businesses in which each agrees to adhere to a baseline level of verification before accepting an assertion. SAML can be bound with multiple communication and transport protocols. It can be linked with Simple Object Access Protocol (SOAP) over HTTP [8,9]. Fig. 3. Browser/Artifact Fig. 4. Browser/Post SAML operates without cookies in one of two profiles: browser/artifact and browser/post. Using browser/artifact, a SAML artifact is carried as part of a URL query string as shown in Figure 3, where a SAML artifact is a pointer to an assertion. The steps in Figure 3 are explained as follows. (1) User of an authenticated browser on Server A requests access to a database on Server B. Server A generates a URL redirect, which contains a SAML artifact, to Server B. (2) Browser redirects user to Server B, which receives an artifact pointing to the assertion on Server A. (3) Server B sends artifact to Server A and gets a full assertion. (4) Server B checks the assertion and either validates or rejects the user s request for access to the database. With browser/post, SAML assertions are uploaded to the browser within an HTML form and conveyed to the destination site as part of an HTTP post payload, as show in Figure 4. The steps in Figure 4 are explained as follows.
(1) User of authenticated browser on Server A requests access to database on Server B. (2) Server A generates an HTML form with SAML assertion and returns it to user. (3) Browser posts the form to Server B. (4) Server B checks assertion and either allows or denies user s request for access to database. 3. Design and Implementation of Java-Based SAML APIs We designed and implemented SAML APIs as Java packages as shown in Figure 5. Fig. 5. Java Packages of SAML APIs The classification of packages is based on the specification Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) [8]. We designed three basic packages named assertion, protocol and messaging packages. To support the messaging function, we also designed generator, uitilities and security packages. The implemented SAML APIs are grouped into these packages. The function of each package is as follows. Assertion package: dealing with authentication, authorization and attribution information. Protocol package: dealing with SAML request/response message pairs to process assertions. Messaging package: including messaging frameworks which transmit assertions. Security package: applying digital signature and encryption on the assertions Utilities package: generating UUID, UTC Data format and artifacts, and so on. Generator package: generating SAML request/response messages. The Structure of major packages will be shown as continuous figures. The structure of assertion package is shown in Figure 6. The structure of protocol package is shown in Figure 7. A protocol defines an agreed way of asking for and receiving an assertion [13]. The structure of the messaging package is shown in Figure 8. The messaging package transforms a document into a SOAP message and defines how the SAML messages are communicated over standard transport and messaging protocols [13].
Fig. 6. Structure of ac.sejong.saml.assertion package Fig. 7. Structure of ac.sejong.saml.protocol package Fig. 8. Structure of ac.sejong.saml.messaging <samlp:request IssuenInstant= 2002-08-08T07:58:32.338Z MajorVersion= 1 MinorVersion= 0 RequestID= a207b-a0-aaa4-11d6-9e6d-75a01a1d3688 xmlns:samlp= urn:oasis:names:tc:saml:1.0:protocol > <samlp:attributequery> <saml:subject xmlns:saml= urn:oasis:names:tc:saml:1.0:assertion > <saml:confirmationmethod>urn:oasis:names:tc:saml:1.0:am:password</saml:confirmationmethod> <saml:subjectconfirmationdata> j&5d#siks233$...</saml:subjectconfirmationdata> </saml:subject> <saml:attributedesignaor attributename= //sejong.ac.kr/email attributenamespace= sejong.ac.kr/ams/namespace/common xmlns:saml= urn:oasis:names:tc:saml:1.0:assertion /> </samlp:attributequery> </samlp:request> Fig. 9. Generation of SAML Request Message We verified the message according to the SAML specifications. When we generated SAML request messages as shown in Figure 9, we used RequestGenerator class in generator package (refer to step 1 of Figure 3 and 4). This SAML request message is signatured as shown in Figure 10, using signature class in security.sign package. The signature process of signature class follows XMLsignature standards in the enveloped form. Figure 11 shows the generation of SAML response messages, in which ResponseGenerator class in generator package is used (refer to step 4 of Figure 3 and 4). This SAML response message is also signatured using signature class in security.sign package.
<samlp:request > <ds:signature xmlns:http://www.w3.org/2000/09/xmldig#> <ds:signedinfo> <ds:canonicalizationmethod Algorithm= ></ds:canonicalizationmehtod> <ds:signaturemethod Algorithm= ></ds:signaturemethod> <ds:reference URI= > <ds:transforms><ds:transform Algorithm= ></ds:transform> </ds:transforms> <ds:digestmethod Algorithm= ></ds:digestmethod><ds:digestvalue>.7znaenuew=..</ds:digestvalue> </ds:reference> </ds:signedinfo> <ds:signaturevalue> zqdwdkc </ds:signaturevalue> <ds:keyinfo> <ds:keyvalue> <ds:rsakeyvalue> <ds:modulus> gdadmhy0= </ds:modulus> <ds:exponent>aqab</ds:exponent> </ds:rsakeyvalue> </ds:keyvalue> <ds:x509data> <ds:x509issuerserial> <ds:x509issuername> </ds:x509issuername> <ds:x509issuernumber>1045440891</ds:x509serialnumber> </ds:x509issuerserial> <ds:x509subjectname> </ds:x509subjectname> <ds:x509certificate> Xs+69s= </ds:x509certificate> </ds:x509data> </ds:keyinfo> <samlp:attributequery> </samlp:attributequery> </samlp:request> Fig. 10. SAML Request Message signatured in Enveloped Form <samlp:response InResponseTo= a207b-a0-aaa4-11d6-9e6d-75a01ad3688 IssurInstant= 2003-03-24T14:36:56Z MajorVersion= 1 MinorVersion= 0 ResponseID= 00cda300-0d5e-8521-83c5-c2d9f6847b91 xmlns:saml= urn:oasis:names:tc:saml:1.0:assertion xmlns:samlp= urn:oasis:names:tc:saml:1.0:protocol > <saml:status> <samlp:statuscode Value= saml:success /> <samlp:statusmessage>this is a message about status</samlp:statusmessage> <samlp:statusdetail> </samp:statusdetail> </saml:status> <saml:assertion AssertionID= 00cda300-0d5e-8521-83c5-c2d9f6847b91 IssueInstant= 2003-03-24T14:36:56Z MajorVersion= 1 MinorVersion= 0 > <saml:autherticationstatement AuthenticationMethod= password AuthenticationInstant= 2003-03-24T14:36:56Z > <saml:subject> <saml:nameidentifier>jeongjongil </saml:nameidentifier> </saml:subject> </saml:authenticationstatement> </saml:assertion> </samlp:response> Fig. 11. Generation of SAML Response Message 4. Conclusion We designed and implemented an SSO library supporting the SAML standard. The implemented SAML APIs have following features. Since SAML messages are transmitted through SOAP, XML based message structures are fully preserved. This enables valid bindings. Integrity and non-repudiation are guaranteed by using signatures on transmitted messages. Confidentiality is guaranteed by encryption of transmitted messages. Since XML encryption is applied, each element can be efficiently encrypted. Even though digital signatures on a SAML message using RSA is default and using an XML signature is optional, we fully implemented both APIs in security
package. Specific encryption methods for SAML messaging are not mentioned in the SAML specification and XML encryptions are a suitable candidate for encryption of SAML messages. We also implemented APIs for XML encryption [14]. Recently, Grid systems have adopted Web Services standards that were proposed by W3C and SAML is an XML-based SSO standard for Web Services. SAML will become widely used in Grid Architecture, as distributed applications based on Web Services become popular. We will further apply this SAML library to real word systems such as the Electronic Document Manage Systems (EDMS) and the groupware systems and continue research on authorization for users. References 1. Foster, I., Kesselman C.: The Globus Project: A Status Report. Future Generation Computer Systems, Volume: 15, (1999) 607-621 2. Foster I., Kesselman C., Nick J.M., Tuecke S.: The Physiology of the Grid - : An Open Grid Services Architecture for Distributed Systems Integration, http://www.globus.org/research /papers/ogsa.pdf 3. Web Services Activity, http://www.w3.org/2002/ws 4. Foster I., Kesselman C., Tsudik G., Tuecke S.: A Security Architecure for Computational Grids. Proc. 5th ACM Conference on Computer and Communications Security Conference, (1998) 83-92 5. Volchkov, A.: Revisiting Single Sign-On: A Pragmatic Approach in a New Context. IT Professional, Volume: 3 Issue: 1, Jan/Feb (2001) 39-45 6. Parker, T.A.: Single Sign-On Systems-The Technologies and The Products. European Convention on Security and Detection, 16-18 May (1995) 151-155 7. Pfitzmann, B.: Privacy in Enterprise Identity Federation - Policies for Liberty Single Signon. 3rd Workshop on Privacy Enhancing Technologies (PET 2003), Dresden, March (2003) 8. Assertions and Protocol for the OASIS Security Assertion Markup Language(SAML) V1.0: http://www.oasis-open.org/committees/security 9. Bindings and Profiles for the OASIS Security Assertion Markup Language(SAML) V1.1: http://www.oasis-open.org/committees/security 10. Global Grid Forum OGSA Security Working Group: Use of SAML for OGSA Authorization, http://www.globus.org/ogsa/security 11. Pfitzmann, B., Waidner, B.: Token-based Web Single Signon with Enabled Clients. IBM Research Report RZ 3458 (#93844), November (2002) 12. Frier A., Karlton P., and Kocher P.: The SSL 3.0 Protocol. Net Scape Communications Corporation, Nov 18, (1996) 13. Galbraith, B., Trivedi, R., Whitney, D., Prasad D. V., Janakiraman, M, Hiotis, A., Hankison, W.: Professional Web services Security, Wrox Press, (2002) 14. XML Encryption WG, http://www.w3.org/encryption/2001/