White PapersThe first part of this white paper presents “browser-based” identity federation, which is enabled by eTrust SiteMinder. The second part describes how eTrust TransactionMinder enables “document-based” identity federation security using web services flows.
White PaperUniversal FederationArchitectureEnabling Unified IdentityFederation & Web ServicesSecurityForest YinSecurity ManagementDecember 2006 Untitled DocumentT able of ContentsIntroduction ..........................................................................................................................................................................................................3Document Purpose and Scope..........................................................................................................................................................................3Reference Documents ........................................................................................................................................................................................3Federation Requirements ..................................................................................................................................................................................3Federation Models ..............................................................................................................................................................................................3eTrust SiteMinder Support for SAML Browser Federation ........................................................................................................................4Introducing SAML 2.0 ..................................................................................................................................................................................4SAML 2.0 Concepts and Definitions ..................................................................................................................................................4SAML 2.0 Key Functionality..................................................................................................................................................................4SAML Assertions ....................................................................................................................................................................................5SAML 2.0 Conformance ........................................................................................................................................................................5Web SSO SAML Artifact Profile ................................................................................................................................................................6Web SSO SAML POST Profile ....................................................................................................................................................................7Single Log-Out (SLO)....................................................................................................................................................................................7SAML Attribute Services..............................................................................................................................................................................7eTrust SiteMinder Support for WS-Federation ............................................................................................................................................9Introducing WS-Federation ........................................................................................................................................................................9WS-Federation Concepts and Definitions ........................................................................................................................................9WS-Federation Passive Requestor Profile Key Functionality ........................................................................................................9WS-Federation Passive Profile Sign On....................................................................................................................................................9WS-Federation Passive Profile Sign Out ..................................................................................................................................................9eTrust SiteMinder Support for the Liberty Alliance Project ....................................................................................................................10eTrust SiteMinder Federation Deployment Architecture and Components ........................................................................................10eTrust SiteMinder Federation Security Services (FSS) Components................................................................................................11eTrust SiteMinder Federation End Point..................................................................................................................................................11Partner Solution Guidelines ......................................................................................................................................................................12Browser-Based Federation Example Scenarios............................................................................................................................................12eTrust TransactionMinder Support For Document-Based Federation....................................................................................................13eTrust TransactionMinder XML Agent....................................................................................................................................................14Sender-Vouches Approach ..............................................................................................................................................................................14Holder-Of-Key Approach ..........................................................................................................................................................................15Document-Based Federation Use Cases ................................................................................................................................................15Sender-Vouches Scenario ....................................................................................................................................................................15Holder-Of-Key Scenario ......................................................................................................................................................................16Conclusion ..........................................................................................................................................................................................................17Glossary................................................................................................................................................................................................................17Technical References........................................................................................................................................................................................202Untitled DocumentIntroductionThe growth of partnerships into seamless e-businessnetworks is one of the most significant trends in theevolution of Internet commerce. Some of the mostsuccessful global enterprises have achieved a very highlevel of coordination between their own informationtechnology (IT) systems and those of their customers,suppliers and partners. This IT coordination is being usedto differentiate solutions, reduce costs and improvespeed and agility.In business-to-consumer (B2C) scenarios where consumerscommunicate with an enterprise that presents products orservices from multiple partners simultaneously, access toshared resources must be secure and structured to meetthe requirements of each partner in the business relation-ship, while meeting the consumer's needs.In application-to-application (A2A) or business-to-business (B2B) environments where Web services areincreasingly used, remote or partner access to corporatedata and applications must be achieved securely andseamlessly. Effective identity federation benefits both users andenterprises. It provides end users with a seamless cross-domain experience through single sign-on (SSO) and itenables enterprises to expose resources to a larger classof users not directly administered by the enterprise. CA s Universal Federation Architecture (UFA) is designedto provide identity federation within the company andacross external partners for legacy, Web and serviceoriented environments. CA s Universal FederationArchitecture supports the leading federation standardsusing a highly manageable and scalable infrastructure.When used in conjunction with the other components ofCA s Identity and Access Management (IAM) solution,it provides the most comprehensive IAM solution onthe market. While federation technology and markets are still in theirearly stages, CA envisions a day in the near future whenfederation and Web services are clearly seen as criticalelements of enterprise IAM systems. CA is delivering onthis vision today. Document Purpose and ScopeThe purpose of this white paper is to show how CA s IAMsolution (specifically the eTrust SiteMinder and eTrust TransactionMinder components) provides a trueUniversal Federation Architecture.The first part of this white paper presents browser-based identity federation, which is enabled by eTrustSiteMinder. The second part describes how eTrustTransactionMinder enables document-based identityfederation security using Web services flows. Terms and concepts not directly defined in the text areexplained in a short glossary provided at the end of thedocument, together with a list of technical references.Reference DocumentsIn order to better understand this white paper, readersshould be familiar with identity federation concepts, aswell as the basic operation of the eTrust SiteMinder andeTrust TransactionMinder products. Additional information on these topics is provided bythree white papers: " Identity Federation: Concepts, Use Cases and IndustryStandards" eTrust SiteMinder r6 Technical White Paper " eTrust TransactionMinder : Securing Web ServicesWhite PaperFederation RequirementsBoth eTrust SiteMinder and eTrust TransactionMindersolutions are designed to meet the following identityfederation requirements:" Provide a framework built on industry standards (dataformat and message structure) that are independent ofspecific implementations (client type or server type)and network protocols" Provide the ability for business partners to exchangeinformation about their users in a secure way " Protect the privacy of users within a federation, i.e.,keep user identity information secret" Allow each company in a federation to manage theidentities of their own users without relying on acentralized third-party" Support standard security information descriptions oruse existing standard security tokens" Support a standard protocol to exchange securitytokens amongst federation participants" Provide a way to establish trust amongst federationparticipantsFederation ModelsIdentity federation can be achieved through browsers orusing XML documents with Web services. 3Untitled DocumentIn browser-based federation the end user visits websites hosted by business partners. Browser-basedfederation security is provided by eTrust SiteMinderFederation Security Services (FSS) through its support ofthe Security Assertion Markup Language (SAML) andWS-Federation/ADFS.In document-based federation, business partners orbusiness units communicate through XML documentsused to request and obtain Web services. Document-based federation security is provided by eTrustTransactionMinder using SAML, X.509 certificates andUsername security tokens inserted in Web ServicesSecurity (WS-Security) headers.CA UFA s multi-protocol and multi-model supportprovides the flexibility for customers to select theappropriate model and protocol to federate with eachof their partners.eT rust SiteMinder Support forSAML Browser FederationThe browser federation capabilities provided by eTrustSiteMinder are collectively known as eTrust SiteMinderFederation Security Services (FSS). FSS supports SAML 1.0, SAML 1.1 and SAML 2.0 and theWS-Federation/ADFS standards/specifications. The useof these standards/specifications is selectable through apull-down menu, thus enabling an eTrust SiteMinderadministrator to select the appropriate protocol andversion for each federated partner. This positions eTrustSiteMinder to be an excellent choice for a federation hub , where an organization is federating with manydifferent partners using a single system that is an integralpart of the organizations Web access managementinfrastructure.Introducing SAML 2.0 The goal shared by the OASIS Security Services TechnicalCommittee (SSTC) overseeing SAML and the LibertyAlliance Project has been to have a single identityfederation technology. As a result, the Liberty AllianceIdentity Federation Framework (ID-FF 1.2) was mergedwith SAML 1.1 to produce the SAML 2.0 specification.SAML 2.0 provides support for account linking (as found inID-FF 1.2) and attribute-based SSO (as found in SAML 1.x)SAML 2.0 Concepts and DefinitionsMost of the terms listed below were originally borrowedfrom Liberty s ID-FF." Principal: An individual user or a group of users. Principalis synonymous with subject or user." Identity Provider (IdP): A SAML authority (e.g., anenterprise) that produces SAML assertions forprincipals. These SAML assertions are used as sessiontickets to establish federation. Identity provider issynonymous with SAML producer or asserting party " Service Provider (SP): An entity (e.g., an enterprise) thatprovides services and/or goods to principals. A serviceprovider consumes SAML assertions produced by anidentity provider. Service provider is synonymous withSAML consumer or relying party " Federation: An agreement between an identity providerand one or more service providers about the data used todescribe users (e.g., e-mail address, role, membership ina group, or unique (opaque) identifier known only to theidentity provider and service provider)" Enabled Client or Proxy (ECP): A SAML-enabled client is aclient (e.g., a web browser, a cell phone, etc.) that has,or knows how to obtain, knowledge about the identityprovider that a principal wishes to use with the serviceprovider. A SAML-enabled proxy is an HTTP proxy(typically a WAP gateway) that emulates a SAML-enabled client" Metadata: Identifies the distinct roles involved in profiles(Identity Provider, Service Provider, Attribute Authority,Attribute Requester). Metadata specifies data that mustbe agreed upon between partners regarding identifiers,supported profiles, URLs, certificates and keysSAML 2.0 Key FunctionalitySAML 2.0 s functionality is defined in profile categories:" Single Sign-on and Federation: how a service providerobtains a SAML assertion from an identity provider" Name Registration: how service providers and identityproviders specify the name identifier to be used whencommunicating with each other about a principal" Federation Termination Notification: How serviceproviders and identity providers are notified offederation termination" Single Log-out: How service providers and identityproviders are notified of authenticated sessiontermination (a user can log-out at an identity provideror service provider to terminate a session)" Identity Provider Introduction: how a service providerdiscovers which identity providers a principal may beusing" Name Identifier Mapping: How a service providermay obtain a name identifier with which to refer to aprincipal at a SAML Authority" Name Identifier Encryption: How a service provider mayencrypt a name identifier for privacy4Untitled DocumentSAML AssertionsA SAML assertion makes statements about a principal. AllSAML assertions include the following common information:" Issuer ID and issuance timestamp" Assertion ID" Subject" Name " Optional subject confirmation (e.g., a public key)" Optional conditions (under which an assertion is valid) " Optional advice (on how an assertion was made)SAML assertions can include three types of statements:" Authentication statement: issued by an authenticationauthority upon successful authentication of a subject. Itasserts that Subject S was authenticated by Means M atTime T " Attribute statement: issued by an attribute authority,based on policies. It asserts that Subject S is associatedwith Attributes A, B, etc. with values a, b, etc." Authorization decision statement: issued by anauthorization authority which decides whether to grantthe request by Subject S, for Action A (e.g., read, write,etc.), to Resource R (e.g., a file, an application, a webservice), given Evidence ENote: The Authorization Decision Statement has beendeprecated in SAML 2.0. Per the SAML specification, the feature has beenfrozen as of SAML 2.0, with no future enhancementsplanned . As an alternative, the eXtensible AccessControl Markup Language (XACML) provides enhancedauthorization decision features.SAML assertions can be embedded (i.e., a SAML assertioncan contain another SAML assertion). SAML assertionscan be encrypted and signed.SAML 2.0 ConformanceThe following table shows the various levels of SAML 2.0conformance. Identity Providers and Service Providersmust minimally support a number of required profiles (so-called Identity Provider Lite and Service Provider Lite ). Starting from v.6.0 SP3, eTrust SiteMinder FSS supportsthe required level of compliance for Identity Provider Lite and Service Provider Lite (grey parts in the tablebelow). For a future roadmap discussion, please contact CA.5Features (Profiles)Identity Provider Lite Service Provider Lite Web SSO, , HTTP redirectRequiredRequiredWeb SSO, , HTTP POSTRequiredRequiredWeb SSO, , HTTP artifactRequiredRequiredArtifact Resolution, SOAPRequiredRequiredEnhanced Client/Proxy SSO, PAOSRequiredRequiredName Identifier Management, HTTP redirect (IdP-initiated)IdP Full Support OnlySP Full Support OnlyName Identifier Management, SOAP (IdP-initiated)IdP Full Support OnlySP Full Support OnlyName Identifier Management, HTTP redirectIdP Full Support OnlySP Full Support OnlyName Identifier Management, SOAP (SP-initiated)IdP Full Support OnlySP Full Support OnlySingle Logout (IdP-initiated), HTTP redirectRequiredRequiredSingle Logout (IdP-initiated), SOAPOptionalOptionalSingle Logout (SP-initiated), HTTP redirectRequiredRequiredSingle Logout (SP-initiated), SOAPOptionalOptionalIdentity Provider Discovery (cookie)RequiredOptionalUntitled DocumentWeb SSO SAML Artifact ProfileeTrust SiteMinder FSS implements the Web BrowserSAML Artifact Profile as defined by the SAML specifica-tion. The Web Browser SAML Artifact Profile involvestwo sites:" SAML Producer Site: An application that generatesSAML assertions (XML documents) and SAML artifacts.A SAML artifact is a fixed-length, randomly-generatedreference to a SAML assertion " SAML Consumer Site: An application that (1) processesan incoming SAML artifact to define who the SAMLproducer site is, (2) obtains the full SAML assertionfrom the SAML producer site using the SOAP-over-HTTP binding of SAML The process flow of the Web Browser SAML ArtifactProfile is as follows:1. The user visits a SAML producer site and is challengedto present credentials.2. Upon successful authentication, the SAML producer sitegenerates a SAML assertion and a reference to theSAML assertion (SAML artifact).3. The user clicks on a link to a service provider at a SAMLconsumer site.4.The user is redirected to the SAML consumer site withSAML artifact and target URL query parameters. 5. The SAML consumer site processes the SAML artifactand determines who the SAML producer site is.6.The SAML consumer site makes a back-channel SOAPrequest to the SAML producer site for the full assertiondescribing the user. 7. The SAML producer site returns the SAML assertion tothe SAML consumer site in a SOAP message.8.The SAML consumer site authenticates the user byvalidating the SAML assertion.eTrust SiteMinder FSS can be used both as a SAMLproducer (Identity Provider) and SAML consumer (ServiceProvider). In addition, to enable FSS customers to federatewith those partners that do not have a SAML supportingsecurity infrastructure, CA provides a lightweight endpoint solution the eTrust SiteMinder Federation EndPoint, a multi-protocol end point solution with full IdP andSP capabilities.The following table shows the possible Identity Provider Service Provider combinations using eTrust SiteMinderFSS, third-party federation applications and the eTrustSiteMinder Federation End Point, + WS-Federation/ADFS (discussed later).6Figure 1. Web Browser SAML Artifact Profile.Identity ProvidereTrust SiteMinder FSSeTrust SiteMinder FSSeTrust SiteMinder FSSeTrust SiteMinder FSSSAML-Compliant Third-Party ApplicationWS-Federation/ADFSeTrust SiteMinder Federation End PointService ProvidereTrust SiteMinder FSSSAML-Compliant Third-Party ApplicationWS-Federation/ADFSeTrust SiteMinder Federation End PointeTrust SiteMinder FSSeTrust SiteMinder FSSeTrust SiteMinder FSSFigure 2. Identity Provider and Service Provider potential combinations.Untitled DocumentWeb SSO SAML POST ProfileeTrust SiteMinder FSS also implements the Web BrowserSAML Post Profile, as defined by the SAML specification.eTrust SiteMinder can be used both as a SAML producerand SAML consumer.1. The user visits a SAML producer site with informationabout the requested resource at the SAML consumersite attached to the URL. 2. Upon successful authentication, the SAML producersite generates an HTML form containing a SAMLresponse which includes one or more SAML assertions.The SAML producer site returns to the browser thesigned SAML response over HTTP/SSL. (Note: In thisprofile, SAML assertions must have a short lifespan orvalidity period.)3. The browser posts the HTML form containing the SAMLresponse to the SAML consumer site (possibly usingJavaScript) over HTTP/SSL (SAML assertions aretransmitted in plain text, or in the case of SAML 2.0,they can also be encrypted). The consumer site needsto save state (to ensure that there are no duplicaterequests).4. The SAML consumer site processes the SAML assertionand sends an HTTP response to the browser that allowsor denies access to the requested resource at the SAMLconsumer site.eTrust SiteMinder supports both SAML Artifact profileand SAML Post Profile and Administrators can implementthe Artifact profile and post profile concurrently, based ontheir partners requirements.Single Log-Out (SLO) eTrust SiteMinder FSS provides the capability to singlelog-out across federated partner sites through theimplementation of SAML 2.0 Single Log-Out profile.This global log-out service can be initiated via user browserfrom a link at any Service Provider site or Identity Providersite and the associated IdP federation deployment handlesall log-out requests and responses for participating sites.Below is an example SLO process. 1. The user clicks on a log-out link at SP1 site. 2. SP1 then sends an SLO request to the IdP. 3. The Idp processes the request and send SLO requests toother SPs, SP2 in this example.4.SP2 logs the user out and returns an SLO response.5. The IdP then sends an SLO response to SP1 and the useris logged out globally.SAML Attribute ServiceseTrust SiteMinder FSS provides SAML attribute requestand response services through the implementation of theSAML 2.0 specifications. FSS can act as an AttributeAuthority that processes attribute queries and suppliesan assertion with attributes for a user based on the userNameID and it can also act as a SAML Requester thatrequests a SAML assertion with attributes for a user byusing their NameID.Attribute assertions can be used to pass user identityinformation for authorization, personalization, orprovisioning purposes. It is worth noting that the SSOassertion can also be configured to pass attributeinformation as part of the SSO process, but the attributeservice can be used outside of the SSO process. In additionthe attribute authority could be a totally separate entityfrom the Identity Provider that authenticates the user. 7Figure 3. Web Browser SAML Post Profile.Figure 4. Single Log-Out.Untitled DocumentIn the case of an Attribute Authority, a SAML Requestersends a SOAP message with an enclosing SAML 2.0<AttributeQuery> message to an Attribute Authority. The<AttributeQuery> message contains the whichcontains the NameID for the SAML Principal for whomattributes are being requested, as well as the attributesthemselves. A successful will returnAssertions containing attribute statements.In addition to the support of Attribute Authority andAttribute Requester, eTrust SiteMinder authorizationpolicies can be configured to make decisions usingattributes in an attribute assertion at run-time. Thefollowing flow diagram shows the authorization processusing attribute assertion. 1. A user accesses a protected resource. The user mightbe logged in locally or may have authenticated via aSAML assertion.2. The Web Agent at the SAML Requester makes a call tothe local Policy Server determine if the user is authorizedto access the resource. The policy that protects theresource uses a policy expression for authorization witha federated attribute variable.3. The Policy Server tries to resolve these variables butcannot. The Policy Server looks the user up in the localuser store to obtain the user's NameID.4.An attribute query is sent to the AttributeService URLat the Attribute Authority. The AttributeQuery containsthe users NameID and the requested attributes.5. The Attribute Authority returns a SAML responsecontaining an assertion with the requested attributes.6.The SAML Requester completes the resolution ofvariables and then evaulates the policy expression.7. An authorization status message is returned to theWeb Agent.8.Depending on the authorization status, the Web Agentallows or denies access to the requested resource.8Figure 5. SAML Attribute Services.Figure 6. Authorization Process Using Attribute Assertion.Untitled DocumenteT rust SiteMinder Support forWS-Federation & Microsoft s ADFSIntroducing WS-Federation Web Services Federation Language (WS-Federation) is aspecification jointly developed by multiple independentvendors, including Microsoft. WS-Federation providessupport for secure propagation of identity, attribute,authentication and authorization information. By relyingon the models defined in WS-Security, WS-Trust andWS-Policy, WS-Federation enables brokering of trust andsecurity token exchange, support for privacy by hidingidentity and attribute information and federated sign-out. WS-Federation specifications were submitted to OASIS forreview and standardization, but as of this writing is not yetan OASIS standard.WS-Federation Concepts and Definitions" Account Partner: A Federation partner that is trusted bythe Federation Service to provide claims-based securitytokens. It is equivalent to a SAML 2.0 Identity Provider" Resource Partner: A federation partner that trusts theFederation Service to issue claims-based securitytokens. It is equivalent to a SAML 2.0 Service Provider" Claim: A claim is a declaration made by an entity (e.g.name, identity, key, group, privilege, capability, etc)" Security Token: A cryptographically signed data unitthat expresses one or more claims. WS-Federationpassive requestor profile defines four security tokenformats or types - X.509v3, Kerberos, XrML and SAML.For Microsoft s ADFS (Microsoft's WS-Federationpassive requestor implementation) the security tokenformat is a SAML 1.1 assertion wrapped in WS-Trust,WS-Policy and WS-Addressing XML" Passive Requestor: A passive requestor is an HTTPbrowser or application capable of broadly supportedHTTP (e.g. HTTP/1.1)" Passive Requestor Profile: the profile that defines how theWS-Federation model is applied to passive requestorssuch as Web browsers that support the HTTP protocol" Attribute Services: An attribute service is a Web servicethat maintains information (attributes) about principalswithin a trust realm or federation. The term principal, inthis context, can be applied to any system entity, notjust a person" Pseudonym Services: A pseudonym service is a Webservice that maintains alternate identity informationabout principals within a trust realm or federation. Theterm principal, in this context, can be applied to anysystem entity, not just a personWS-Federation Passive Requestor Profile KeyFunctionalityKey functionality defined in the Passive Requestor Profileinclude:" Single Sign-on " Single Log-out" Attribute Services" Pseudonym ServicesWS-Federation Passive Profile Sign-On eTrust SiteMinder FSS supports SSO using the WS-Federation Passive Profile Sign-On service, enablinginteroperability with Microsoft s Active DirectoryFederation Services (ADFS). Both Microsoft ADFS andthe eTrust SiteMinder WS-Federation implementationsupports the SAML 1.1 security token. eTrust SiteMinder FSS can act as:" An Account Partner, whereby eTrust SiteMinder willauthenticate users, generate WS-Federation securitytokens and pass them to Microsoft ADFS acting as aResource Partner using the Federation PassiveRequestor profile" A Resource Partner, whereby eTrust SiteMinder willconsume a WS-Federation security token sent to eTrustSiteMinder from Microsoft ADFS acting as an Accountpartner and establish an eTrust SiteMinder session basedon the contents of the WS-Federation security token" Both an Account Partner and a Resource Partner,whereby one eTrust SiteMinder installation willauthenticate users, generate WS-Federation securitytokens and pass them to a second eTrust SiteMinder orADFS installation that will consume the WS-Federationsecurity token and establish a eTrust SiteMinder sessionbased on the contents of the security tokenThe WS-Federation Passive profile is conceptuallyanalogous to the SAML POST profile with similar processflow. However it uses a SAML 1.1 assertion wrapped inWS-Trust, WS-Policy and WS-Addressing XML and WS-Federation specific HTTP protocol parameters andbindings for redirects.WS-Federation Passive Profile Sign-Out eTrust SiteMinder FSS supports Sign-Out using theWS-Federation Passive profile, enabling sign-outinteroperability with Microsoft Active Directory FederationServices (ADFS). eTrust SiteMinder FSS can be an Account Partner receivinga sign-out request or a Resource Partner receiving a sign-out or a sign-out cleanup request and perform sign-outoperations.9Untitled DocumentAs mentioned earlier in this document, Liberty s ID-FFlayer has been rolled into the SAML 2.0 standard,currently supported by eTrust SiteMinder. CA will supportthe other Liberty Alliance sets of specifications (ID-WSFand ID-SIS) in future versions of eTrust SiteMinder, basedon customer requirements.eT rust SiteMinder FederationDeployment Architecture andComponentseTrust SiteMinder FSS is licensed as an add-on solutionto eTrust SiteMinder IT provides SAML/WS-Federationfederation components in both the eTrust SiteMinder Webagent and the eTrust SiteMinder Policy Server. Built on topof eTrust SiteMinder, FSS inherits the reliability, availabilityand scalability (RAS), as well as manageability of eTrustSiteMinder and is well suited to provide federationcapabilities that enables eTrust SiteMinder customers tofederate with a large number of their partners.In addition to the FSS as a federation solution for eTrustSiteMinder customers, to enable FSS customers tofederate with those partners that do not have aSAML/WS-Federation/ADFS-compliant securityinfrastructure, CA provides a lightweight (which does notrequire eTrust SiteMinder) partner enablement solution eTrust SiteMinder Federation End Point, a multi-protocolend point solution with IdP and SP capabilities. Below is a deployment architecture diagram shows thateTrust SiteMinder FSS customers can federate with theirpartners with different solutions and protocols and have itconfigured on a per partner level.As an Account Partner eTrust SiteMinder will handle sign-out requests initiated locally or at an ADFS based ResourcePartner or a eTrust SiteMinder based Resource Partner.Syntactically there is no difference in a sign-out requestinitiated at an Account Partner or a Resource Partner.As a Resource Partner eTrust SiteMinder will handle signout requests initiated locally. As a Resource Partner eTrustSiteMinder will handle sign-out cleanup request initiatedat an ADFS based Account Partner or at a eTrustSiteMinder based Account Partner.eTrust SiteMinder Support for theLiberty Alliance ProjectThe Liberty Alliance Project (loosely referred to asLiberty Alliance or Liberty) is an industry organizationthat currently includes over 160 member companiesworldwide, including CA. The purpose of the Liberty Alliance is to create a set ofspecifications for identity federation in network environ-ments (for details on the Liberty Alliance specifications,please refer to the CA white paper entitled IdentityFederation: Concepts, Use Cases and Industry Standards).The Liberty Alliance provides three sets of specifications:" ID-FF (Federation Framework): Identity federation andmanagement using identity / account linkage, SSO,sessioning. ID-FF relies on SAML for its security tokens(extended SAML Assertions) and request-responsemethod (SAML Protocol)." ID-WSF (Web Services Framework): Identity servicedescription and discovery, attribute sharing." ID-SIS (Services Interface Specification): Interoperableidentity services (including calendering, alert, wallet,contact, personal profile).10Figure 7. eTrust SiteMinder acting as a Federation hub.Untitled DocumenteT rust SiteMinder FederationSecurity Services (FSS) ComponentseTrust SiteMinder FSS is a tightly integrated service ofeTrust SiteMinder and provides SAML federationcomponents in both the eTrust SiteMinder Web agentand the eTrust SiteMinder Policy Server.eTrust SiteMinder Federation Security Services include thefollowing components:" SAML (or WS-Federation) Authentication Scheme forSP (or RP)This eTrust SiteMinder authentication scheme enablesan eTrust SiteMinder protected site to act as anassertion consumer by making configurationinformation available to the Federation Web Services toretrieve an assertion; validating an assertion; mappingthe assertion data to a local user; and establishing aeTrust SiteMinder session at the consumer site. The authentication scheme maps remote users at anIdP (or AP) site to local users at a SP (or RP) site. Themapping is defined as part of the authentication schemeconfiguration. User mapping information enables theauthentication scheme to locate the correct user recordfor authentication.The SAML (or WS-Federation) authentication schemeis part of the eTrust Policy Server Option Pack. Afterinstallation, the consumer site administrator can usethe eTrust Policy Server user interface to define andconfigure authentication schemes and use them toprotect specific resources." SAML (or WS-Federation) Assertion Generatorfor IdP (or AP)The assertion generator creates an assertion for a userwho has a session at an IdP (or AP) site. The Web Agent invokes the assertion generator whena request for an assertion is made. The assertiongenerator creates an assertion based on the usersession and information configured in the policy store. In the SAML artifact profile, the assertion is then placedin the eTrust SiteMinder session server and a referenceto the assertion is returned to the Web Agent in theform of a SAML artifact. The Web Agent is responsiblefor sending the SAML artifact to the SAML consumersite (also known as an affiliate ) and later retrievingthe SAML assertion for the consumer site. However, inSAML Post Profile or in WS-Federation, no sessionserver is required and the assertion is wrapped in to aprotocol message and posted to the SP (or RP) throughHTML form post.The SAML assertion generator is installed by the eTrustPolicy Server Option Pack. After installation, the IdP (orAP) site administrator can use the eTrust Policy Serveruser interface to define and configure affiliates forassertion generation." Federation Web ServicesFederation WS is an eTrust SiteMinder Web Agentcomponent, that is delivered as part of the web agentoption pack, that provides protocol handling for assertionproducer and assertion consumer functionality: SAML (or WS-Federation) assertion retrieval service SAML (or WS-Federation) credential collection at anassertion consumer siteFederation Web Services are implemented as servletsdeployed in an application server. The eTrust SiteMinderWeb Agent is used to protect access to each FederationWeb Service. The Service Provider (or Resource Partner) and IdentityProvider (or Account Partner) configuration informationis cached in the Federation Web Services component tominimize calls to the Policy Server to obtain config-uration information. eTrust SiteMinder Federation End Point The eTrust SiteMinder Federation End Point is a newlightweight partner enablement federation solution.The solution enables partners who do not have existingfederation infrastructure to federate with eTrustSiteMinder FSS customers. This eTrust SiteMinderFederation End Point provides the same level of protocolsupport as eTrust SiteMinder FSS provides and can act asan Identity Provider or Service Provider without requiringeTrust SiteMinder (or an equivalent solution from anothervendor) to be installed at the partner site. While the eTrust SiteMinder Federation End Point providesfull federation functions and quick partner enablement,there are some key concepts that should be understood:" It only interoperates with eTrust SiteMinder FSS and isnot intended to be a general purpose federation solutionthat interoperates with other federation solutions " It does not provide access control capabilities like thoseprovided by eTrust SiteMinder. It provides federatedidentity mapping, SSO and SLO capabilities, but leaveslocal access control and resource protection to theapplications or the existing access control solution thatthe partner may have. For a partner acting as an IdP, integration is required toprovide a mechanism for supplying an eTrust SiteMinderFederation End Point with information needed to look upa user s current authenticated session data (for example,a cookie). For a partner acting as an SP, required inte-11Untitled Documentgration involves enabling the eTrust SiteMinderFederation End Point to supply information needed bythe target application or system to set a valid sessioncookie or other security context for the user. AnIntegration Kit is provided with limited out-of-boxapplication integrations and an SDK is provided forcustom integrations with application sessions or accesscontrol infrastructures. Partner Solution GuidelinesAs a CA customer using eTrust SiteMinder FSS, tofederate with your partners, your partner of course alsoneeds a standards supporting federation solution. If thepartner has an existing federation solution such as eTrustSiteMinder FSS or competing Web Access Managementwhich supports federation, eTrust SiteMinder FSS canfederate directly with those solutions using SAML. Below are some logical steps you may go through withyour partner to determine how best to federate:1. If the proposed federation partner has a commercialaccess control product like eTrust SiteMinder, it is bestfor them to work with the federation capabilities oftheir existing solution. 2. If this is not the case, but the partner has Windows2003 R2 with ADFS in their environment, eTrustSiteMinder FSS can interoperate with ADFS using theWS-Federation protocol. 3. Otherwise, if the partner needs a light-weight solutionto be able to federate with eTrust SiteMinder FSS, theeTrust SiteMinder Federation End Point with multi-protocol and full IdP and SP capabilities is a goodoption.Browser-Based Federation ExampleScenarios The following use case scenarios demonstrate how theeTrust SiteMinder Federation Security Services worktogether to provide enhanced federation services toemployees, customers and suppliers. While the use casesare illustrated using eTrust SiteMinder SAML ArtifactProfile support, other protocols or profiles could also beused to deliver on the requirements of the use case. Federation Based On Account LinkingIn this case (see Figure 8), eTrust SiteMinder is deployedat both sites by installing the Web Agent with the WebAgent Option pack on a Web server machine, the eTrustPolicy Server with the eTrust Policy Server Option Pack onanother machine. The installations are the same for bothsites. Note, however, that any other SAML-compliantapplication could also be used at either site (this scenariodemonstrates that eTrust SiteMinder supports SAML-producing and SAML-consuming requirements equally well).In this example, Workplace.com is acting as the SAMLproducer site. When an employee of Workplace.comaccesses an employee portal at www.workplace.com theeTrust SiteMinder Web Agent provides the initialauthentication. When the employee clicks on a link atwww.workplace.com to view her health benefits atwww.health.com, the link makes a request to the eTrustSiteMinder Web Agent at www.workplace.com. The WebAgent at www.workplace.com calls the SAML assertiongenerator, which creates a SAML assertion, inserts theassertion into the eTrust SiteMinder session server andreturns a SAML artifact. The eTrust SiteMinder WebAgent redirects the user to www.health.com with theSAML artifact.12Figure 8. eTrust SiteMinder Federation Based On Account Linking.Untitled DocumentHealth.com is acting as the SAML consumer site. Theredirect request with the SAML artifact is handled by theSAML credential collector service that is part of theFederation Web Services at www.Health.com. The SAMLcredential collector calls the SAML artifact authenticationscheme to obtain the location of the SAML assertionretrieval service at Workplace.com. The SAML credentialcollector calls the SAML assertion retrieval service atwww.workplace.com. The SAML assertion retrieval serviceat www.workplace.com retrieves the SAML assertion fromthe eTrust SiteMinder session server and returns it to theSAML credential collector at www.health.com.The SAML credential collector then passes the SAMLassertion to the SAML artifact authentication scheme forvalidation and session creation, issues an eTrustSiteMinder session cookie to the user s browser. At thispoint the user is allowed access to resources atHealth.com based on policies defined in the eTrust PolicyServer at Health.com and enforced by the eTrustSiteMinder Web Agent at Health.com.Federation Based On RolesThis example illustrates how the eTrust SiteMinder FSScomponents can be deployed at Workplace.com andPartsSupplier.com (see Figure 9) to provide federationbased on roles. eTrust SiteMinder is deployed at both sitesin the same manner as the federation scenario based onaccount linking shown in the previous section. Theinteractions between the user and the sites are similar(PartsSupplier.com is acting as the SAML consumer). The configuration is similar to federation based onaccount linking except for the following:" The administrator at Workplace.com defines theaffiliate for PartsSupplier.com with an attribute thatindicates the department that the user works in. Thiscauses the SAML assertion generator to include thedepartment attribute as part of the user profile in aSAML assertion created for PartsSupplier.com" The administrator at PartsSupplier.com defines a SAMLartifact authentication scheme for Workplace.com andconfigures it to extract the department attribute fromthe SAML assertion and to search the user directory atPartsSupplier.com for the user record that matches thedepartment value extracted from the SAML assertion.The administrator defines one user profile record foreach department that is allowed to accessPartsSupplier.com s web siteeT rust TransactionMinder SupportFor Document-Based FederationDocument-based federation security is realized over Webservices flows. eTrust TransactionMinder is designed tosecure access to Web services by leveraging eTrustSiteMinder architecture. eTrust TransactionMinderprovides similar WAM services as does eTrust SiteMinder(authentication, authorization, audit), but does it for XMLWeb services.The eTrust TransactionMinder federation securityfunctionality is predicated on the use of WS-Securityheaders in SOAP messages, which eTrust TransactionMindercan both consume and/or produce (see Document-BasedFederation Use Cases below). eTrust TransactionMinder provides three types of securitytokens supported by WS-Security: Password digest,X.509 certificates, SAML assertions, as defined in theWS-Security specification.13Figure 9. eTrust SiteMinder Federation Based On Roles.Untitled DocumenteTrust TransactionMinder XML AgentFigure 10 describes an eTrust TransactionMinder XMLagent layered on top of an eTrust SiteMinder agent toprovide support for incoming XML message processing.An eTrust TransactionMinder XML Agent includes twoparts linked through inter-process communication (IPC):" eTrust SiteMinder Web Agent: A plug-in that providesencrypted communication between the eTrustTransactionMinder XML Agent and the eTrust PolicyServer" Java-based XML Services: provided in an XML SDKincluding open-source technology for parsingdocuments, executing XPath expressions, supportingSOAP and XML signature crypto librariesThe XML SDK also includes a WS-Security authenticationhandler and a WS-Security response handler. The WS-Security authentication handler processesinbound requests (WS-Security consumer functionality):" Parses WS-Security tokens, verifies XML digitalsignatures" Passes information to the eTrust Policy Server (viathe eTrust SiteMinder Web Agent). The Policy Servervalidates the certificate containing the public key usedfor verifying a digital signatureThe WS-Security response handler processes outboundrequests (WS-Security producer functionality):" Creates WS-Security tokens (Password Digest, X.509certificate, SAML assertion)" Creates a timestamp (if required)" Signs the document (if required)Note: The eTrust Policy Server processing is defined by aWS-Security policy server response, hence the name ofthe handler.eTrust TransactionMinder provides federation over Webservices flows, based on the WS-Security SAML TokenProfile defined in the WS-Security specification using twoapproaches:" Sender-Vouches " Holder-Of-Key Sender-Vouches ApproachIn this case, the intermediary (for example, the user senterprise) uses WS-Security/SAML credentials to accessWeb services on behalf of the user. In other words, thesender (the enterprise) vouches for the user.The user s enterprise signs the SAML assertion and theSOAP envelope body with their enterprise private key.14Figure 10. TransactionMinder XML Agent.Figure 11. Sender-Vouches.Untitled DocumentHolder-Of-Key ApproachIn this case, the user obtains WS-Security/SAMLcredentials from a home site and accesses Web servicesat other service provider sites. This is often used as anauthentication Web service which is then leveraged bymany other Web services.1. The digital signature signs the SAML assertion with theenterprise private key.2. The digital signature signs the SOAP envelope bodywith the user private key matching the user public key.Document-Based Federation Use CasesDocument-based federation use cases illustrate howeTrust TransactionMinder provides federation using theSender-Vouches and Holder-Of-Key approaches (seeFigures 13 and 14). Sender-Vouches ScenarioIn this use case, Workplace.com has a purchasingagreement with PinSupplies.com. PinSupplies.com has abusiness relationship with E-Ship.com. The end user logs on to her procurement application withher username and password. The procurement applicationprovides a list of Workplace.com s various suppliers. Theend user clicks on the PinSupplies button and is presentedwith a purchase order in an HTML page. She fills out thepurchase order and then clicks the Submit button on theHTML form. The procurement application turns the HTML form into anXML document that it inserts in the envelope body of aSOAP message. The procurement application then insertsthe end user s credentials in the envelope header of theSOAP message, together with Workplace.com s customeridentity. 1. eTrust TransactionMinder authenticates the user requestfor the Purchasing Web service at PinSupplies.comusing the document credentials collector (DCC)authentication scheme. The purchase order isprocessed by PinSupplies.com.2. eTrust TransactionMinder generates a SAML assertion(including the original end user s security information)and inserts it in the WS-Security (WSSE) header partof the SOAP message. eTrust TransactionMinder signsboth the SAML assertion and the body of the SOAPmessage with PinSupplies.com s private key.3. The Purchasing Web service at PinSupplies.com posts theSOAP message generated by eTrust TransactionMinderto the Shipping Web service at E-Ship.com.15Figure 12. Holder-Of-Key.Figure 13. Sender-Vouches Scenario.Untitled Document4.At E-Ship.com, eTrust TransactionMinder authenticatesthe request using the WS-Security-SAML sender-vouchesauthentication scheme. eTrust TransactionMinderchecks the signature covering the SAML assertionand the message body and validates that the SAMLassertion was issued by a trusted partner (PinSupplies.comvouches for the user). E-Ship.com can now processthe shipment order for the original requester atWorkplace.com.Note: This scenario demonstrates the ability of eTrustTransactionMinder to be both at PinSupplies.com andE-Ship.com, but either site can have an alternativeWS-Security/SAML-compliant third-party securityapplication if desired.Holder-Of-Key Scenariowww.example1.com is an identity provider, i.e., Example1.comgenerates security tokens to be used to access resourceshosted by remote service providers. In this scenario, theend user is an employee of Workplace.com, but the enduser could also be an employee of Example1.com.www.example2.com is a remote service provider thataccepts credentials produced by www.example1.com. Example1.com and Example2.com have a businessagreement. In this scenario, Example1.com andExample2.com are two separate companies (differentInternet domains), but they could also be twodepartments of the same company. 1. The end user s application signs the request forauthentication using the user s private key and posts itto the Authentication Web service at Example1.com.2. eTrust TransactionMinder authenticates the userrequest using the XML Signature (XML DSIG)authentication scheme. eTrust TransactionMindergenerates the SAML assertion, inserts the user scertificate into the SAML assertion, then signs theassertion with Example1.com s private key.3. The Authentication Web service at Example1.comreturns the signed SAML assertion just created (in araw XML document or in a SOAP/WS-Securityresponse).4.The user s application at Workplace.com inserts theSAML assertion in a WS-Security header as part of aSOAP request, posts the request to Example2.com sWeb service.5. At Example2.com, eTrust TransactionMinder authen-ticates the request using the WS-Security SAMLholder-of-key authentication scheme. eTrustTransactionMinder checks the SAML assertionsignature and the user s signature on the messagebody, validates that the SAML assertion was issued bya trusted partner (in this case Example1.com), validatesthat the user is in the user store.Note: This scenario demonstrates the ability of eTrustTransactionMinder to be both at Example1.com andExample2.com, but either site can have a third-partysecurity application provided that application is compliantwith the standards involved (XML signature, WS-Security,SAML).16Figure 14. Holder-Of-Key Scenario.Untitled DocumentConclusionAs identity and access management becomes theintegration point for user and application administrationacross heterogeneous environments and architectures,emerging federation security standards and industryinitiatives play a strong role in lowering cost andcomplexity.Today, eTrust SiteMinder and eTrust TransactionMinder,key Web access management components of CA scomprehensive IAM solution, provide a comprehensiveidentity federation security solution for both Webapplications and Web services. When used together theyprovide the industries most complete federation solution&truly a Unified Federation Architecture.eTrust SiteMinder provides a full-fledged browser-based federation security solution bridging differentstandards and industry initiatives including SAML andWS-Federation/ADFS.eTrust TransactionMinder provides a leading-edgeplatform to support document-based federation throughXML flows and Web services security, based onWS-Security, SAML and digital certificates. GlossaryThis glossary is designed as a quick reference to thewords or concepts not explicitly defined in the text ofthis document. Words in italics are defined in their ownentries. Entries prefixed with an asterisk (*) are specificto eTrust SiteMinder and eTrust TransactionMinder andhow SAML is used in those products.Access Control. Protection of resources againstunauthorized access.Access Control List (ACL). A list of users or groups ofusers whose identities are associated with specific accessrights.Access Rights. Authorized interactions an entity (e.g., auser) can have with a resource (e.g., Read, Delete, Modify,Add, etc.).Account Linking. A one-to-one mapping of a user identitybetween a remote site (SAML producer site) and a localsite (SAML consumer site).Assertion. A set of claims.Assertion Consumer URL. eTrust SiteMinder s SAMLcredential collector URL. The Assertion Consumer URLincludes a SAML artifact and Target URL that are used bythe credential collector to obtain the SAML assertion fromthe producer site and redirect the user to the targetresource originally requested.17Attribute. The property or characteristic of an entity usedfor authorization purposes.Authentication. Verifying an entity s identity based onsubmitted credentials. There are three authenticationfactors: Something you have, e.g., credentials issued by atrusted authority such as a passport or a certificate;Something you know, e.g., a shared secret such as apassword; Something you are, e.g., biometric information. Authentication Scheme. A way of processing authenti-cation. eTrust SiteMinder and eTrust TransactionMinderoffer many authentication schemes based on authenticationrequirements, for example, simple username / password,X.509 certificates, HTML forms (for collecting the user scredentials), XML Signature, hardware tokens (providingunique passwords), proxies (SecureID, RADIUS), NTLM(for authenticating users based on their Windows NTlog-in name and password instead of challenging usersfor credentials), custom authentication schemes createdwith the Authentication API. eTrust SiteMinder andeTrust TransactionMinder authentication schemes aredefined in the eTrust Policy Server and enforced byeTrust SiteMinder/eTrust TransactionMinder agents.Authorization. Granting access to specific resources basedon an authenticated entity s entitlements. Base64. Binary information may need to be included intextual form in email or XML documents. If you want toinsert binary information in an XML document, you needto first encode it in text. Base64 is an algorithm thatencodes binary data using 64 ASCII characters (hence thename). Every binary input stream is broken down into six-bit segments, each segment is mapped to an ASCIIcharacter, the = (equal) sign (the 64th ASCII character)is used for padding a segment that has less than 6 bits.Note that Base64 information is not human readable, butit s not encrypted either, it s just a string of charactersrepresenting binary input. Certificate (or X.509 Public-Key Certificate). A datastructure digitally signed by the authority that issues it. Acertificate binds an entity to a key (a certificate is used tosend the public key to a receiving party). A certificateincludes standard fields such as certificate ID, issuer s DN,validity period, owner s DN, owner s public key, etc. Cipher. Encryption and decryption algorithms.Ciphertext. Encrypted data (the opposite is plaintext).Claim. A statement made by an entity (user identity andattributes are typical claims).Confidentiality. see Privacy.Untitled DocumentCredentials. Data used to establish an entity s identity.Typically, credentials can be a username / password or acertificate (see also Authentication).Data Integrity. Making sure that data can t be alteredwhen in transit between sending and receiving parties(see also Digital Signature).Decryption. The process of transforming ciphertext backinto its original clear text using a cryptographic key.Digest (or Message Digest). The result of applying a one-way algorithm (e.g., MD5, SHA-1, etc.) to an input streamin order to compress it (see also MAC).Digital Signature. Verifying that a message came from theintended entity (authentication) and that the message wasnot altered during transit (data integrity). Digital signaturesuse public key encryption as follows: The sending partygenerates a digest of the data to be sent, encrypts thedigest with its private key, then sends the result with itspublic key and the (plaintext) data. The receiving partyuses the sending party s public key to decrypt the signatureand performs the same calculation (hash function) on thedata (see also XML Signature Specification). Distinguished Name (DN). A string of characters withseveral fields used to describe an identity. Typically, a DNincludes a common name (CN), an organizational unit(OU), an organization (O), a location (L), a state orprovince (S), a country (C) and other optional fields. Example of a DN: CN=Marc Chanliau, OU=Engineering,O=ComputerAssociates, L=Waltham, S=Massachusetts,C=USDomain Name. Plain text identity of an organization (orentity) on the Internet (for example, netegrity.com).Domain Name Service (DNS). A program that translatesthe domain name into an Internet Protocol (IP) address(for example 172.26.6.32). Encryption. The process of creating ciphertext from cleartext using a cryptographic key (see also XML EncryptionSpecification). Encryption provides confidentiality (orprivacy).Entitlement. Access right defined by one or severalattributes.Entity. Any object that interacts with other entities, suchas a person (e.g., an end-user) or a system (e.g., anapplication program or a hardware device). Synonyms:Principal (human entity), Subject (human or system entity).Federation. See Identity Federation.Hash. See Digest. Hash Function. A one-way transformation that maps avariable-size input (e.g., a key, a password, etc.) to a fixed-size string (the hash value, typically between 64 and 256bits). Identity. Unique and meaningful information associatedwith an entity. An identity can be described simply by auser name and a password, or more universally by anX.500 Distinguished Name (DN). An identity can alsoinclude attributes, such as an Internet Protocol (IP)address or a role.Identity Federation. Ability to manage and deliverdifferent representations of an entity's identity to differentpartners.Integrity. See Data Integrity.Intersite Transfer URL. A URL that transfers a user from aSAML producer site to a SAML consumer site. The IntersiteTransfer URL triggers the eTrust SiteMinder Web Agent atthe producer site to request that the eTrust Policy Servercreate an assertion for the user. The eTrust Policy Serverreturns the SAML artifact for the assertion to the Webagent, then the Web agent redirects the user back to theSAML credential collector at a SAML consumer site.Issuing Party (or Issuing Entity). The party (or entity) thatauthenticates a user or a service (also see Relying Party).Key (or Cryptographic Key). A mathematical functionused to encrypt or decrypt data. In a symmetric cipher, thekey to encrypt and decrypt data is the same. In anasymmetric cipher, a public key is used to encrypt the data,which can only be decrypted by a matching private key.The owner of the key pair (i.e., the recipient of theencrypted message) has to make the public key known toother parties (see also Public Key).Log-in. Presenting credentials to an authentication systemin order to start a session with that system. Synonyms:Log-on, Sign-on.Log-out. Terminating a current session. Synonym: Sign-out.Message Authentication Code (MAC). A secure messagedigest. A MAC requires a secret key that is shared by thesending and the receiving parties.No Access URL. A URL where the eTrust SiteMinder WebAgent at a SAML consumer site redirects a user if the userdoes not have the appropriate rights to access therequested resource.18Untitled DocumentPolicy (or Security Policy). A set of rules designed tocontrol access to a resource. eTrust SiteMinder and eTrustTransactionMinder policies have a structure that includesthe following elements: Rule (allows or denies access to aspecific resource), User Directory (identifies users),Response (an (optional) action that occurs when a rule isenacted), IP Address (the location that the policy appliesto), Time (the time when the policy may or may not beenacted), Active Policy (optional custom extension of apolicy).Policy Domain. In the eTrust Policy Server, a logical set ofresources grouped together for administrative purposes, e.g.,a Marketing policy domain, a Support policy domain, etc.Policy Expression. The mapping of an entity s identityand/or attributes to authorized actions on a protectedresource. Policy Decision Point (PDP). A logical entity that makesauthorization decisions on its own behalf or on behalf ofother entities that requested it. For example, the eTrustPolicy Server is the physical implementation of a PDP.Policy Enforcement Point (PEP). A logical entity thatrequests and enforces authorization decisions. Forexample, eTrust SiteMinder and eTrust TransactionMinderagents are physical implementations of PEPs.Principal. See Entity.Privacy. The ability to keep information secret. Privacyinvolves a message, for example a Web service request, anemail, or a business document, as well as the identity ofthe sending and receiving parties. Privacy can be achievedby encrypting the content of a message and obfuscatingthe sending and receiving parties identities.Private Key. In an asymmetric cipher model, a private keyis used to decrypt ciphertext. Also, a private key is used forencryption with digital signatures (see Key, Public Key, DigitalSignature).Public Key. In an asymmetric cipher model, the receivingparty s public key (possibly stored in a public repository) isused to encrypt plaintext, the receiving party s matchingprivate key is used to decrypt the ciphertext. In otherwords, when a party wants to send sensitive data toanother party, all the sending party needs is the public keyof the receiving party. Public-key certificates are used toguarantee the integrity of public keys. Also, the public key isused for verifying digital signatures (see Key, Private Key,Digital Signature).Realm. In eTrust SiteMinder and eTrust TransactionMinder,a collection of resources grouped together according tosecurity requirements. Realms are generally associatedwith policy domains (a policy domain can contain severalrealms). Also, a realm, as defined in many standardsspecifications, represents a single unit of trust betweenthe source and the destination of a request.Relying Party (or Relying Entity). A party (or entity) thatparticipates in a federation and accepts to take an actionbased on information provided by an Issuing Party.Response. A response lets a eTrust SiteMinder or eTrustTransactionMinder administrator manage the userexperience by passing data to an application that canpersonalize content (eTrust SiteMinder) or further actionon an XML message (eTrust TransactionMinder).When a rule is enacted, the eTrust Policy Server returnsresponse attributes to a eTrust SiteMinder or eTrustTransactionMinder agent.Role. The active part of an entity, e.g., an administratorrole or an agent role.Rule. A rule defines a set of actions for the resource itprotects. In eTrust SiteMinder and eTrust TransactionMinder,a rule structure includes the following elements: Realm(identifies a group of resources and authentication), Resource(Web pages, Web services, scripts, Java resources such asservlets, EJBs), Action (action allowed on a resource), Time(time when the rule may or may not be enacted), ActiveRule (optional custom extension of a rule).SAML Artifact. A SAML artifact is designed to reference aSAML assertion stored in the eTrust SiteMinder sessionserver at a SAML producer site. The SAML artifact enablesa SAML consumer site to retrieve an assertion documentfrom the SAML producer site. A SAML artifact is a fixed-length (~40-byte) opaque string including the artifactissuer identity along with the set of possible resolutionendpoints and a cryptographic message handle value(generated by the issuer) . You can customize your ownartifact.SAML Consumer Site. A site that has a SAML engine ableto consume SAML assertions according to the WebBrowser Profile of SAML.SAML Producer Site. A site that has a SAML engine ableto generate SAML assertions and a SAML artifact accordingto the Web Browser Profile of SAML.Secure Socket Layer (SSL). Transport-level data-communication protocol providing authentication (thecommunication is established between two trusted partiesusing certificates), confidentiality (the data exchanged isencrypted), message integrity (the data is checked forpossible corruption).19Untitled DocumentSecurity Token. A collection of claims (e.g., a SAMLassertion, a Kerberos ticket, a certificate, etc.).Session. The interactions between various entities.Single Sign-On (SSO). The ability to be authenticatedat one site and be able to visit other sites withoutrepeated log-in.Subject. See Entity.Target URL. The URL or resource that a user is ultimatelytrying to access using a SAML assertion.Trust. A relationship between entities whereby one entityrelies on the other for delivering a service securely. Trust ispredicated on privacy and security policies betweeninteracting parties.Uniform Resource Identifier (URI). A string of charactersused to identify a resource on the Web. A URI can beexpressed in an abstract way as a URN (persistent) or as aURL (changeable).Uniform Resource Name (URN). The persistent identifier (oritem name) of a resource (the URN for a particular resourcecannot be changed). A URN can be expressed as a URL.Uniform Resource Locator (URL). The location of aresource on the Web and the protocol used to access thatresource. A URL can be changed.X.509 Public-Key Certificate. See Certificate.XML Signature Specification. The binding of the sender sidentity (or signing entity ) to an XML document. Thedocument is signed using the sender s private key, thesignature is verified using the sender s public key. A digitalsignature ensures non-repudiation of the signing entity(authentication) and proves that messages have not beenaltered since they were signed (see also Digital Signature).XML Encryption Specification. Defining how digitalcontent is encrypted and decrypted, how the encryptionkey information is passed to a recipient, how encrypteddata is identified to facilitate decryption.T echnical References" Kerberos: http://web.mit.edu/kerberos/www/" Liberty Alliance: http://www.projectliberty.org/" Security Assertion Markup Language (SAML):http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security" WS-Security: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss" XML Encryption: http://www.w3.org/TR/xmlenc-core/" XML Signature: http://www.w3.org/TR/xmldsig-core/Copyright 2006 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informationalpurposes only. To the extent permitted by applicable law, CA provides this document As Is without warranty of any kind, including, without limitation, any implied warranties of merchantability orfitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document including, without limitation, lost profits,business interruption, goodwill or lost data, even if CA is expressly advised of such damages. MP276081206
