Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
8Activity
0 of .
Results for:
No results containing your search query
P. 1
Web Single Sign-On Authentication using SAML,, IJCSI, Volume 2, August 2009.

Web Single Sign-On Authentication using SAML,, IJCSI, Volume 2, August 2009.

Ratings: (0)|Views: 2,947|Likes:
Published by IJCSI Editor
Companies have increasingly turned to application service
providers (ASPs) or Software as a Service (SaaS) vendors to
offer specialized web-based services that will cut costs and
provide specific and focused applications to users. The
complexity of designing, installing, configuring, deploying, and
supporting the system with internal resources can be eliminated
with this type of methodology, providing great benefit to
organizations. However, these models can present an
authentication problem for corporations with a large number of
external service providers. This paper describes the
implementation of Security Assertion Markup Language
(SAML) and its capabilities to provide secure single sign-on
(SSO) solutions for externally hosted applications.
Companies have increasingly turned to application service
providers (ASPs) or Software as a Service (SaaS) vendors to
offer specialized web-based services that will cut costs and
provide specific and focused applications to users. The
complexity of designing, installing, configuring, deploying, and
supporting the system with internal resources can be eliminated
with this type of methodology, providing great benefit to
organizations. However, these models can present an
authentication problem for corporations with a large number of
external service providers. This paper describes the
implementation of Security Assertion Markup Language
(SAML) and its capabilities to provide secure single sign-on
(SSO) solutions for externally hosted applications.

More info:

Published by: IJCSI Editor on Sep 10, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

05/11/2014

pdf

text

original

 
IJCSI International Journal of Computer Science Issues, Vol. 2, 2009
ISSN (Online): 1694-0784ISSN (Printed): 1694-0814
 
IJCSIIJCSI
 
41
 
Web Single Sign-On Authentication using SAML
Kelly D. LEWIS, James E. LEWIS,
 
Ph.D.Information Security, Brown-Forman CorporationLouisville, KY 40210, USA
kellydlewis@gmail.com 
Engineering Fundamentals, Speed School of Engineering, University of LouisvilleLouisville, KY 40292, USA
 jel@louisville.edu 
Abstract
Companies have increasingly turned to application serviceproviders (ASPs) or Software as a Service (SaaS) vendors tooffer specialized web-based services that will cut costs andprovide specific and focused applications to users. Thecomplexity of designing, installing, configuring, deploying, andsupporting the system with internal resources can be eliminatedwith this type of methodology, providing great benefit toorganizations. However, these models can present anauthentication problem for corporations with a large number of external service providers. This paper describes theimplementation of Security Assertion Markup Language(SAML) and its capabilities to provide secure single sign-on(SSO) solutions for externally hosted applications.
 Keywords:
 
Security, SAML, Single Sign-On, Web, Authentication
1.
 
Introduction
Organizations for the most part have recently startedusing a central authentication source for internalapplications and web-based portals. This single sourceof authentication, when configured properly, providesstrong security in the sense that users no longer keeppasswords for different systems on sticky notes onmonitors or under their keyboards. In addition,management and auditing of users becomes simplifiedwith this central store.As more web services are being hosted by externalservice providers, the sticky note problem has reoccurredfor these outside applications. Users are now forced toremember passwords for HR benefits, travel agencies,expense processing, etc. - or programmers must developcustom SSO code for each site. Management of usersbecomes a complex problem for the help desk andcustom built code for each external service provider canbecome difficult to administer and maintain.In addition, there are problems for the external serviceprovider as well. Every user in an organization will needto be set up for the service provider’s application,causing a duplicate set of data. Instead, if theorganization can control this user data, it would save theservice provider time by not needing to set up andterminate user access on a daily basis. Furthermore, onecentral source would allow the data to be more accurateand up-to-date.Given this set of problems for organizations and theirservice providers, it is apparent that a solution is neededthat provides a standard for authentication information tobe exchanged over the Internet. Security AssertionMarkup Language (SAML) provides a secure, XML-based solution for exchanging user security informationbetween an identity provider (our organization) and aservice provider (ASPs or SaaSs). The SAML standarddefines rules and syntax for the data exchange, yet isflexible and can allow for custom data to be transmittedto the external service provider.
2.
 
Background
The consortium for defining SAML standards andsecurity is OASIS (Organization for the Advancement of Structured Information Standards). They are a non-profitinternational organization that promotes the developmentand adoption of open standards for security and webservices. OASIS was founded in 1993 under SGML(Standard Generalized Markup Language) Open until itsname change in 1998. Headquarters for OASIS arelocated in North America, but there is active memberparticipation internationally in 100 countries on fivecontinents [1].
 
IJCSI International Journal of Computer Science Issues, Vol. 2, 2009
IJCSIIJCSI
 
42SAML 1.0 became an OASIS standard toward the end of 2002, with its early formations beginning in 2001. Thegoal behind SAML 1.0 was to form a XML framework to allow for the authentication and authorization from asingle sign-on perspective. At the time of this milestone,other companies and consortiums started extendingSAML 1.0. While these extensions were being formed,the SAML 1.1 specification was ratified as an OASISstandard in the fall of 2003.The next major revision of SAML is 2.0, and it becamean official OASIS Standard in 2005. SAML 2.0 involvesmajor changes to the SAML specifications. This is thefirst revision of the standard that is not backwardscompatible, and it provides significant additionalfunctionality [2]. SAML 2.0 now supports W3C XMLencryption to satisfy privacy requirements [3]. Anotheradvantage that SAML 2.0 includes is the support forservice provider initiated web single sign-on exchanges.This allows for the service provider to query the identityprovider for authentication. Additionally, SAML 2.0adds “Single Logout” functionality. The remainder of this text will be discussing implementation of a SAML2.0 environment.There are three roles involved in a SAML transaction –an asserting party, a relying party, and a subject. Theasserting party (identity provider) is the system inauthority that provides the user information. The relyingparty (service provider) is the system that trusts theasserting party’s information, and uses the data toprovide an application to the user. The user and theiridentity that is involved in the transaction are known asthe subject.The components that make up the SAML standard areassertions, protocols, bindings and profiles. Each layerof the standard can be customized, allowing specificbusiness cases to be addressed per company. Since eachcompany’s scenarios could be unique, theimplementation of these business cases should be able tobe personalized per service and per identity providers.The transaction from the asserting party to the relyingparty is called a SAML assertion. The relying partyassumes that all data contained in the assertion from theasserting party is valid. The structure of the SAMLassertion is defined by the XML schema and containsheader information, the subject and statements about thesubject in the form of attributes and conditions. Theassertion can also contain authorization statementsdefining what the user is permitted to do inside the webapplication.The SAML standard defines request and responseprotocols used to communicate the assertions betweenthe service provider (relying party) and the identityprovider (asserting party). Some example protocols are[4]:
 
Authentication Request Protocol – defines howthe service provider can request an assertionthat contains authentication or attributestatements
 
Single Logout Protocol – defines themechanism to allow for logout of all serviceproviders
 
Artifact Resolution Protocol – defines how theinitial artifact value and then therequest/response values are passed between theidentity provider and the service provider.
 
Name Identifier Management Protocol – defineshow to add, change or delete the value of thename identifier for the service providerSAML bindings map the SAML protocols onto standardlower level network communication protocols used totransport the SAML assertions between the identityprovider and service provider. Some example bindingsused are [4]:
 
HTTP Redirect Binding – uses HTTP redirectmessages
 
HTTP POST Binding – defines how assertionscan be transported using base64-encodedcontent
 
HTTP Artifact Binding – defines how anartifact is transported to the receiver usingHTTP
 
SOAP HTTP Binding – uses SOAP 1.1messages and SOAP over HTTPThe highest SAML component level is profiles, or thebusiness use cases between the service provider and theidentity provider that dictate how the assertion, protocoland bindings will work together to provide SSO. Someexample profiles are [4]:
 
IJCSI International Journal of Computer Science Issues, Vol. 2, 2009
ISSN (Online): 1694-0784ISSN (Printed): 1694-0814
 
IJCSIIJCSI
 
43
 
Web Browser SSO Profile – uses theAuthentication Request Protocol, and any of thefollowing bindings: HTTP Redirect, HTTPPOST and HTTP Artifact
 
Single Logout Profile – uses the Single LogoutProtocol, which can log the user out of allservice providers using a single logout function
 
Artifact Resolution Profile – uses the ArtifactResolution Protocol over a SOAP HTTPbinding
 
Name Identifier Management Profile – uses thename Identifier management Protocol and canbe used with HTTP Redirect, HTTP POST,HTTP Artifact or SOAPTwo profiles will be briefly discussed in more detail, theartifact resolution profile and web browser SSO profile.The artifact resolution profile can be used if the businesscase requires highly sensitive data to pass between theidentity provider and service provider, or if the twopartners want to utilize an existing secure connectionbetween the two companies.This profile allows for a small value, called an artifact tobe passed between the browser and the service providerby one of the HTTP bindings. After the service providerreceives the artifact, it transmits the artifact and therequest/response messages out of band from the browserback to the identity provider. Most likely the messagesare transmitted over a SSL VPN connection between thetwo companies. This provides security for the message,plus eliminates the need for the assertions to be signed orencrypted which could potentially reduce overhead.When the identify provider receives the artifact, it looksup the value in its database and processes the request.After all out of band messages are transmitted betweenthe identity provider and service provider, the serviceprovider presents the information directly to the browser.The web browser SSO profile may be initiated by theidentify provider or the service provider. If initiated bythe identity provider, the assertion is either signed,encrypted, or both. In the web browser SSO profile, allof the assertion information is sent at once to the serviceprovider using any of the HTTP bindings and protocols.The service provider decrypts if necessary and checks formessage integrity against the signature. Next, it parsesthe SAML XML statements and gathers any attributesthat were passed, and then performs SSO using theAssertion Consumer Service. The diagram in Figure 1shows the identity provider initiated SAML assertion.
Figure 1: Identity Provider Initiated SAML Assertion Flowchart
If the user accesses the external webpage without passingthrough the internal federated identity manager first, theservice provider will need to issue the SAML requestback to the identity provider on behalf of the user. Thisprocess of SSO is called service provider initiated. Inthis case, the user arrives at a webpage specific for thecompany, but without a SAML assertion. The serviceprovider redirects the user back to the identity provider’sfederation webpage with a SAML request, and optionallywith a RelayState query string variable that can be usedto determine what SAML entity to utilize when sendingthe assertion back to the service provider.After receiving the request from the service provider, theidentity provider processes the SAML request as if itcame internally. This use case is important since itallows users to be able to bookmark external sitesdirectly, but still provides SAML SSO capabilities withbrowser redirects. Figure 2 demonstrates this serviceprovider initiated use case.The most popular business use case for SAML federationis the web browser SSO profile, used in conjunction withthe HTTP POST binding and authentication requestprotocol. The implementation and framework sectionwill discuss this specific use case and the security neededto protect data integrity.

Activity (8)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
VTR Ravi Kumar liked this
VTR Ravi Kumar liked this
ronnyew liked this
aprboy liked this
saasira liked this
nforkix liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->