A sample business case best illustrates how SiteMinder federation can solve a common business problem.
In this business case, Financepro is a financial planning firm that recently bought the banking firm BankLtd to provide private banking to its clients. These two companies have different information infrastructures, but they want to appear as one company to their customers. To solve this problem, they set up a federated partnership.
By establishing a federated relationship, the two companies can provide a seamless customer experience using single sign-on. Customers can travel between Financepro and BankLtd without constantly being challenged to authenticate. Additionally, the sharing of customer identities and customer information can further customize the user experience and cross-promote the financial products of each partner.
The following illustration shows the federated partnership between Financepro and BankLtd. The flow of communication is based on a SAML 2.0 Service Provider-initiated single sign-on.
The illustration describes the following information flow:
For this partnership to work, decide how the partnership functions before implementing the relationship using Federation Manager.
The issues to consider include:
Your decisions help structure the business partnership.
Business partners have their own method of defining user identity in their respective user stores. How users are identified determines how one partner can map its users to the other partner.
Consider the following scenarios:
Account linking is the method of user identification.
Identity mapping is the method of user identification. At FinancePro, a customer is identified as JohnDoe, while at BankLtd this same customer is identified as DoeJ. The partners must agree on a user attribute profile to use for identity mapping.
Account provisioning is the method for user identification. Provisioning an account can require creating an account for a user or simply populating an existing user account with information in the SAML assertion.
The user identification decision determines what information is sent as the user identity in the assertion.
User mapping is the ability to establish a relationship between a user identity at one business and a user identity at another business. Map remote users at the asserting party to local users at the relying party.
The types of mapping are as follows:
One-to-one mapping, or account linking, links an account at the asserting party to an account at the relying party.
The following illustration shows one-to-one mapping.
N-to-one mapping allows several user records at a producing authority to be mapped to one user record or profile at a consuming authority. An administrator at the relying party can use n-to-one mapping for a group of remote users without maintaining a record for each remote user.
The following illustration shows n-to-one mapping:
For legacy federation, user mapping is configured as part of a federation authentication scheme. For partnership federation, user mapping is configured as part of the name ID and attribute settings.
When a customer at FinancePro accesses a resource at BankLtd, the NameID is always in the assertion. This identifier allows BankLtd to determine who the customer is and the level of access to allow for that customer.
The NameID can establish a federated identity when the user store at each partner identifies the users in the same way with the same ID.
The following figure shows the user store at each site with the same employee IDs.
Federation Manager lets you configure account linking as part of the partnership configuration process. You specify a NameID format and Name ID type, which determines the type of value that defines the Name. You associate the specific Name ID type, with a static, user, or DN attribute from a user directory. The NameID that Federation Manager includes in the assertion conforms to the configuration you define.
When the relying party receives the assertion, the user disambiguation process at BankLtd occurs. The process links the NameID value in the assertion to a record in its user store.
An investor at Financepro authenticates and selects a link to access information at BankLtd. The investor is taken directly to the accounts area of the BankLtd website without having to sign on.
BankLtd maintains user identities for all customers at Financepro, but the identities differ from the identities at FinancePro. For example, at FinancePro, JohnDoe is a customer. At BankLtd, this same customer is identified as DoeJ. Regardless, BankLtd must control access to sensitive portions of the company website. To establish the federated identity, the partners agree on an attribute that maps to the appropriate identity for a single customer at either site.
The partners agree on which attribute to use during an out-of-band exchange of information, meaning that the agreement is not part of any communication in any message over a channel. For this example, the attribute that the partners agree upon is a certified financial planner license number, referred to as the CFPNum in each user store.
When a customer tries accessing the federated resource at BankLtd, the request triggers the single sign-on process. The assertion that is generated at FinancePro contains the CFPNum attribute. When BankLtd receives the assertion, an application at its site has to perform the user disambiguation process. The process relies on the attribute to determine which profile identity is used for the request.
The following illustration shows how the same users are identified differently at each partner.
SiteMinder Federation lets you configure identity mapping as part of the partnership configuration process. For the NameID and attribute configuration, you define an attribute called CFPID. Associate this attribute with the user attribute CFPNum, which is the name of the attribute in the user store at each partner.
SiteMinder Federation includes the attribute in the assertion. When BankLtd receives the assertion, the user disambiguation process links the attribute in the assertion to the appropriate record in its user store.
Partnership federation can work with provisioning applications at the relying party to establish an identity.
A client at Financepro, Mary Smith, authenticates and clicks a link to access information at BankLtd. Initially, BankLtd cannot find a user account for Mary Smith. BankLtd wants to protect sensitive portions of its website while allowing new customers.
BankLtd has configured federation to implement provisioning to establish the new federated identity for Mary Smith. SiteMinder redirects Mary Smith to the provisioning server at BankLtd. The provisioning application, using the federated identity information, creates a user account in the user store.
The following illustration shows the user stores at FinancePro and BankLtd.
Federation lets you configure provisioning as part of the partnership configuration at the relying party. In this example, you select remote provisioning and determine how assertion data is delivered to the BankLtd provisioning server. This configuration enables the dynamic creation of a user entry in the user store.
Federation Manager offers two ways of using attributes to customize target applications.
You can include attributes from a user store record in an assertion to identify a user for the purpose of customizing an application.
Servlets, web applications, and other custom applications can use attributes to display customized content or enable and disable other custom features. When used with web applications, attributes can implement fine-grained access control by limiting user activity at the target site. For example, you send an attribute variable named Account Balance and set it to reflect the account holdings of the user at BankLtd.
Attributes take the form of name/value pairs. When the relying party receives the assertion, it makes the attribute values available to applications.
The relying party receives a set of assertion attributes, which can be mapped to a set of application attributes being delivered to the target application.
For example, FinancePro includes an assertion attribute CellNo=5555555555. At BankLtd, this attribute name is transformed to an application attribute Mobile=5555555555. The attribute name is converted but the value remains the same.
Multiple assertion attributes can also be transformed into a single application attribute. For example, FinancePro sends an incoming assertion with the attributes Acct=Savings and Type=Retirement and transformed at BankLtd into FundType= Retirement Savings.
Determining the profile for a partnership depends on the binding that each side can support.
For a new federation, there are no legacy requirements for either partner. Therefore, the recommended profile to use for single sign-on is SAML 2.0 POST profile. SAML 2.0 POST profile offers secure transmission of assertion data and the configuration process is simpler than SAML Artifact profile. If, however, the agreement of two partners requires SAML Artifact, this binding can also be implemented.
For legacy federation deployments that use Active Directory Federation Services (ADFS), configure WS-Federation.
|
Copyright © 2012 CA Technologies.
All rights reserved.
|
|