The federation APIs support the manipulation of policy store data related to Affiliate Domain objects, which can include Affiliates, Service Providers, and Resource Partners.
The CA SiteMinder® federation products support SAML 1.x, SAML 2.0, and WS-Federation profiles. Partners have the ability to exchange user profile information in a secure manner.
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);
A SAML 2.0 affiliation consists of Service Providers and Identity Providers that have a shared Name ID namespace. Identity Providers also share the user disambiguation properties across the affiliation.
A SAML 2.0 affiliation can have multiple Service Providers and Identity Providers. However, a Service Provider or Identity Provider can belong to no more than one SAML 2.0 affiliation.
Example:
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:
Any authentication scheme can be used to authenticate the user.
This validation occurs transparently to the user.
SiteMinder supports authorization that uses the values of predetermined user attributes from a remote site 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 preferred 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 a customized rate sheet.
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.
In the Policy Management API, the Sm_PolicyApi_SAMLRequesterAttr_t structure defines an attribute that can be requested by the SAML Requester. It specifies the actual name of the attribute known by the Attribute Authority, as well as a local name used in Federation attribute variables. The local name maps to a variable defined in the SAML 2.0 authentication scheme.
When configuring single sign-on at the Identity Provider, you can configure more than one endpoint for the Assertion Consumer Service, the service that enables a Service Provider to consume a SAML assertion. Each endpoint you configure 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 a part of a Service Provider 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 (Artifact or POST).
In the Policy Management API, you can, for example, add a new Assertion Consumer Service to the Service Provider programmatically by calling the Sm_PolicyApi_AddAssertionConsumerServiceToSAMLSP() function as follows:
iSmApiRetCode = Sm_PolicyApi_AddAssertionConsumerServiceToSAMLSP (
pSmApiSessionHandle, &structSAMLSPACS2, pszOid);
Parameters:
In addition, the API includes a function to remove an Assertion Consumer Service and a function to retrieve all the Assertion Consumer Services defined in the Service Provider object. The C Policy Management API sample program, smpolicyapiexample.cpp, shows how these functions are implemented.
The C sample program smpolicyapi has been augmented for the affiliate functionality.
To run the affiliate portions
Three options have been added to the smpolicyapi program.
Answering Y causes smpolicyapi to:
Answering Y causes smpolicyapi to:
Answering Y causes smpolicyapi to delete the affiliate domain.
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 Signout in the WS-Federation environment are implmented 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.
The C Policy Management API sample program, smpolicyapiexample.cpp, includes examples of how to define, list, and delete a Resource Partner, as well as define, list, and delete a WS-Federation authentication scheme.
|
Copyright © 2014 CA.
All rights reserved.
|
|