The CA SiteMinder® federation programming interfaces allows businesses in a federated relationship across the Internet to securely share information about users visiting any of the federated sites. Users can access federated sites without having to supply credentials more than once.
Affiliated sites share user information through an industry-standard Security Assertion Markup Language (SAML) document called an assertion.
The CA SiteMinder® federation product supports SAML 1.x and SAML 2.0 protocols.
A SAML assertion includes:
Note: You can modify the default assertion that the Policy Server generates. You do so through a custom Java class that you create with the Java APIs in the CA SiteMinder® SDK.
SAML 1.x support lets a user access a consumer site directly or from an assertion producer site without having to supply credentials more than once.
When a user requests access to a protected resource at an affiliate site, the Policy Server at the producer site is notified. After authenticating the user (if the user has not yet been authenticated), the Policy Server generates a SAML assertion from the affiliate object associated with the consumer site.
An application at the affiliate site then retrieves the SAML assertion from the Policy Server, and uses the information for authorization purposes and any other required purpose.
For example, suppose a user logs into a site for a bank (the producer site). The producer includes Policy Server software. The Policy Server contains an affiliate object that represents a site offering credit card services, and also other affiliate objects that represent other sites affiliated with the bank. When a user is authenticated at the producer, the user can click the link for the credit-card site and access the site without having to re-enter his credentials.
The pseudo-code in this section illustrates the following operations:
Note: Comments using <> notation represent code omitted for ease of understanding. Return code checking is omitted for ease of understanding.
# 1. Initialize the API
use Netegrity::PolicyMgtAPI;
$policyapi = Netegrity::PolicyMgtAPI‑>New();
$session = $policyapi‑>CreateSession("adminid", "adminpwd");
# 2. Add an affiliate domain
$affdomain = $session‑>CreateAffDomain("name", "description");
# 3. Add a previously obtained user directory to the affiliate domain
# <Obtain $userdir via $session‑>GetAllUserDirs>
$affdomain‑>AddUserDir($userdir);
# 4. Create an affiliate in the affiliate domain
$affiliate = $affdomain‑>CreateAffiliate("affname", "password",
http://authurl, 60, 30);
# 5. Add users from a previously obtained user table to the affiliate
# <Obtain $user via $userdir‑>GetContents>
$affdomain‑>AddUser($user);
# 6. Add an attribute for the affiliate
$affdomain‑>AddAttribute(1, "staticAttrName=StaticAttrValue");
# 7. Get an existing affiliate domain
$affiliate = $affdomain‑>GetAffiliate("affname");
# 8. Get all the affiliates in an affiliate domain
@affiliates = $affdomain‑>GetAllAffiliate();
# 9. Get all the attributes in an affiliate
@affiliateAttrs = $affiliate‑>GetAllAttributes();
# 10. Remove an affiliate domain
$session‑>DeleteAffDomain($affiliate);
With SAML 2.0, security assertions are shared between the following entities within a federation:
An Identity Provider generates assertions for principals within a SAML 2.0 federation. The Identity Provider sends the SAML assertion to the Service Provider where the principal is attempting to access resources.
A Service Provider makes applications and other resources available to principals within a federation, using the identity information provided in an assertion. A principal is a user or another federation entity.
The Service Provider uses a SAML 2.0 authentication scheme to validate a user based on the information in a SAML 2.0 assertion.
Identity Providers and Service Providers can belong to a SAML affiliation. A SAML affiliation is a group of SAML entities that share a name identifier for a single principal.
Service Providers and Identity Providers can belong to an affiliation; however, an entity can belong to no more than one affiliation. Service Providers share the Name ID definition across the affiliation. Identity Providers share the user disambiguation properties across the affiliation.
Using affiliations reduces the configuration required at each Service Provider. Additionally, using one name ID for a principal saves storage space at the Identity Provider.
By sharing security assertions, a principal can log in at one site (the site acting as the Identity Provider), and then access resources at another site (the Service Provider) without explicitly supplying credentials at the second site.
For example:
Any authentication scheme can be used to authenticate the user.
This validation is transparent to the user.
The pseudo-code in this section illustrates the following operations:
# 1. Initialize the API
use Netegrity::PolicyMgtAPI;
$policyapi = Netegrity::PolicyMgtAPI‑>New();
$session = $policyapi‑>CreateSession("adminid", "adminpwd");
# 2. Retrieve the affiliate domain for the Service Provider
$affDom=$session‑>GetAffDomain("AffiliateDomain");
# 3. Assign metadata constants to variables
$SAML_NAME=SAML_NAME;
$SAML_SP_AUTHENTICATION_URL=SAML_SP_AUTHENTICATION_URL;
$SAML_KEY_SPID=SAML_KEY_SPID;
$SAML_SP_IDPID=SAML_SP_IDPID;
$SAML_AUDIENCE=SAML_AUDIENCE;
$SAML_SP_ASSERTION_CONSUMER_DEFAULT_URL=
SAML_SP_ASSERTION_CONSUMER_DEFAULT_URL;
$SAML_SP_NAMEID_ATTRNAME=SAML_SP_NAMEID_ATTRNAME;
$SAML_SKEWTIME=SAML_SKEWTIME;
# 4. Assign values to the Service Provider metadata
%hsh=($SAML_NAME=>'My Service Provider',
$SAML_SP_AUTHENTICATION_URL=>
'http://www.mysite.com/redirect.jsp',
$SAML_KEY_SPID=>'http://www.spprovider.com',
$SAML_SP_IDPID=>'http://www.idpprovider.com',
$SAML_AUDIENCE=>'SSOAudience',
$SAML_SP_ASSERTION_CONSUMER_DEFAULT_URL=>
'http://www.defaultconsumer.com',
$SAML_SP_NAMEID_ATTRNAME=>'attribute'
);
# 5. Create the Service Provider
$sp=$affDom‑>CreateSAMLServiceProvider(\%hsh);
# 6. Retrieve users from the directory associated with the # affiliate domain—in this case, users in the group HR
$userDir=$session‑>GetUserDir("MyNtDirectory");
$usr=$userDir‑>LookupEntry("HR");
# 7. Add the users to the Service Provider
$sp‑>AddUser($usr);
# 8. Update the Service Provider's default skewtime to 100
$sp‑>Property($SAML_SKEWTIME,"100");
# 9. Save the update
$sp‑>Save();
# 10. Print the updated skewtime
print "\n";
print $sp‑>Property($SAML_SKEWTIME);
SiteMinder supports authorization for user access to a resource by requesting the values of predetermned user attributes from a remote site and then using those values as the basis for the authorization decision. The request contains no session information, because the user is not necessarily authenticated on the remote site.
For example, imagine a customer logs on to a car rental agency site to inquire about rates. The customer is authenticated by the agency, but to provide a competitive rate, the agency uses information from the customer's prefered airline. The car rental agency puts in a request to the airline's Web site to obtain the customer's quality code, which is based on the customer's accrued frequent flier miles. The airline returns the value of the quality code, for instance, 1A, and the car agency displays the appropriate rate sheet to the customer.
In this example, the car rental agency acts as what is know as the the SAML Requester, and the airline acts as what is known as a SAML Attribute Authority. Note that the customer is not authenticated by the Attribute Authority.
The Policy Server implements this kind of authorization decision by using variables within policy expressions. In the policy expressions, Federation attribute variables associate an attribute with a remote Attribute Authority. When the policy server attempts to resolve the Federation attribute variable, it determines the Attribute Authority from which to request the value of the attribute.
The Perl Policy Management API includes the following three methods in the PolicyMgtSession object to support authorization based on user attributes:
The PolicyMgtSAMLServiceProvider‑>AddAttribute method supports the addition of an attribute to the Service Provider (the Attribute Authority) that can be requested by a SAML Requester.
When configuring single sign-on at the Identity Provider, you can specify more than one endpoint for the Assertion Consumer Service, the service that enables a Service Provider to consume a SAML assertion. Each endpoint is assigned a unique index value, instead of a single, explicit reference to an Assertion Consumer Service URL. The assigned index can be used as part of a Service Provider's request for an assertion that it sends to the Identity Provider. This enables you to have a different Assertion Consumer Service at the Service Provider for different protocol bindings.
In a Perl script, you specify the index value, the protocol binding, and the URL of the indexed endpoint using the AddAssertionConsumerServiceToSAMLSP() method in the PolicyMgtSAMLServiceProvider object as follows:
$res = $sp‑>AddAssertionConsumerServiceToSAMLSP(index, protocolBinding, URL);
This method returns a PolicyMgtSAMLSPACS object. There are also methods in PolicyMgtSAMLServiceProvider for retrieving all Assertion Consumer Service objects and for removing an Assertion Consumer Service.
The PolicyMgtSAMLSPACS object includes methods to retrieve values for the index, protocol binding, and Assertion Consumer URL.
The WS-Federation specification provides a protocol for how passive clients (such as Web browsers) implement the federation framework. ADFS is Microsoft's implementation of the WS-Federation Passive Requestor Profile.
Web SSO and sign-out in this environment are implemented using Account Partners and Resource Partners. An Account Partner authenticates users, provides WS-Federation security tokens, and passes them to a Resource Partner. The Resource Partner consumes security tokens and establishes a session based on the contents of the WS-Federation security token.
For SiteMinder to act as an Account Partner, an administrator must define the Resource Partner that will be consuming security tokens. This is done by defining a Resource Partner in an Affiliate domain. For SiteMinder to act as a Resource Partner, an administrator must define the Account Partner that is going to supply security tokens. This is done by defining a WS-Federation authentication scheme.
In a Perl script, you define a Resource Partner by calling the PolicyMgtAffDomain‑>CreateWSFEDResourcePartner method as follows:
$aff = $affDomain‑>CreateWSFEDResourcePartner(propsHash_ref);
propsHash_ref is a reference to a hash table of metadata properties defined for the Resource Partner.
This method returns a PolicyMgtWSFEDResourcePartner object. The PolicyMgtWSFEDResourcePartner object includes methods for managing users in the Resource Partner (AddUser, GetAllUsers, and RemoveUser). Note that the PolicyMgtWSFEDResourcePartner‑>Property() method does not submit changes to the data store. You must call the PolicyMgtWSFEResourcePartner‑>Save() method.
To define an Account Partner in a Perl script you create an instance of a WS-Federation authentication scheme by calling PolicyMgtSession‑>CreateWSFEDAuthScheme(). You can set or retrieve metadata properties for this authentication scheme by calling PolicyMgtSession‑>WSFEDAuthSchemeProperties().
There are no methods for deleting or retrieving a WS-Federation authentication scheme specifically. You use the DeleteAuthScheme, GetAuthScheme, and GetAllAuthSchemes as you would for any other type of authentication scheme. .
The sample scripts AffiliateDemo.pl, SAMLServiceProvider.pl, WSFEDAccountPartner.pl, and WSFEDResourcePartner.pl are provided with legacy federation.
If not installed already Import ampolicy.smdif into the Policy Store before using the sample script. The default location of ampolicy.smdif is <siteminder_install_dir>\db\SMdif.
Affiliate objects representing sites in a federated business network are contained within a Policy Server affiliate domain. An affiliate domain can contain SAML 1.x affiliates and SAML 2.0 Service Providers.
An affiliate domain also contains references to one or more user directories associated with the affiliates and Service Providers in the domain, and to the administrator accounts that can manage the domain.
You can use the Command Line Interface to configure affiliate objects and the affiliate domain where they reside.
|
Copyright © 2014 CA.
All rights reserved.
|
|