Configuring SAML. NetIQ 4.2

Error Message

Unable to complete authentication request.

Cause

The password provided does not conform to the

Windows password complexity policy in Active

Directory. Ensure that Active Directory is configured to use a secure port, such as 636, and that the user’s password conforms to the complexity policy. If you encounter this error, you must reset the password on the Windows machine.

Can occur when users are allowed to create accounts from a service provider’s login page, when the service provider uses Active Directory for the user store.

Configuring SAML 2.0

This section explains how to use the SAML 2.0 protocol to set up the trust with internal and external identity providers, service providers, and Embedded Service Providers (ESPs). Topics include:

“Understanding How Access Manager Uses SAML” on page 423

“Configuring a SAML 2.0 Profile” on page 427

“Creating a SAML 2.0 Service Provider” on page 428

“Creating a SAML 2.0 Identity Provider” on page 428

“Executing Authorization Based Roles Policy During SAML 2.0 Service Provider Initiated

Request” on page 429

“Contracts Assigned to a SAML 2.0 Service Provider” on page 430

“Editing a SAML 2.0 Service Provider’s Metadata” on page 433

“Configuring a SAML 2.0 Authentication Request” on page 433

“Configuring the SAML 2.0 Authentication Response” on page 437

“Defining Options for SAML 2.0” on page 438

“Defining Session Synchronization for the A-Select SAML 2.0 Identity Provider” on page 443

“Configuring the Liberty or SAML 2.0 Session Timeout” on page 443

“Modifying the Authentication Card for Liberty or SAML 2.0” on page 444

“Configuring Multiple SAML 2.0 Service Providers on the Same Host for a Single SAML Identity

Provider” on page 445

“Configuring Active Directory Federation Services with SAML 2.0 for Single Sign-On” on page 445

Understanding How Access Manager Uses SAML

Security Assertions Markup Language (SAML) is an XML-based framework for communicating security assertions (user authentication, entitlement, and attribute information) between trusted identity providers and trusted service providers. For example, an airline company can make assertions to authenticate a user to a partner company or another enterprise application, such as a car rental company or hotel.

Identity Server allows SAML assertions to be exchanged with trusted service providers that use

SAML servers. Using SAML assertions in each Access Manager component protects confidential information by removing the need to pass user credentials between the components to handle session management.

418

Configuring Authentication

An identity provider using the SAML protocol generates and receives assertions for authentication, according to the SAML 1.0, 1.1, and 2.0 specifications described on the Oasis Standards Web site

(http://www.oasis-open.org/specs/index.php) .

This section describes how Access Manager uses SAML. It includes the following topics:

“Attribute Mapping with Liberty” on page 424

“Trusted Provider Reference Metadata” on page 424

“Identity Provider Process Flow” on page 425

“SAML Service Provider Process Flow” on page 426

Attribute Mapping with Liberty

Attribute-based mapping involves one website communicating identity information about a subject to another website to support transactions. However, the identity information might be some characteristic of the subject, such as a role. The attribute-based mapping is important when the subject’s identity is either not important, must not be shared, or is insufficient on its own.

To interoperate with trusted service providers through the SAML protocol, Identity Server distinguishes between different attributes from different SAML implementations. Access Manager uses Liberty attributes in the SAML administration. When you specify which attributes to include in an assertion, or which attributes to use when locating the user from an assertion, these attributes must always be specified in the Liberty format.

In an attribute map, SAML attributes from each vendor’s implementation is converted to Liberty attributes. (See

“Configuring Attribute Sets” on page 61 .)

You can find detailed information about SAML 2.0 on the OASIS Standards Web site (http:// www.oasis-open.org/specs/) .

Trusted Provider Reference Metadata

Identity Server generates metadata for server communication and identification. You can obtain metadata through URL or XML document and then enter it in the system while creating the reference.

Metadata is traded with federation partners and supplies various information regarding contact and organization information located at Identity Server. Metadata is generated automatically for SAML

2.0. You enter it manually for SAML 1.1.

IMPORTANT:

The SAML 2.0 and Liberty 1.2 protocols define a logout mechanism whereby the service provider sends a logout command to the trusted identity provider when a user logs out at a service provider. SAML 1.1 does not provide such a mechanism. For this reason, when a logout occurs at the SAML 1.1 service provider, no logout occurs at the trusted identity provider. A valid session is still running at the identity provider, and no credentials need to be entered. To log out at both providers, users must navigate to the identity provider that authenticated them to the SAML 1.1 service provider and log out manually.

Identity Provider Process Flow

The following illustration provides an example of an Identity Server automatically creating an authenticated session for the user at a trusted SAML service provider. PP indicates a Personal Profile

Service as defined by the Liberty specification.

Configuring Authentication

419

Figure 5-20

SAML Service Provider Process Flow

SAML Servicer Provider xyz.com

User/Browser

3

1

3

4 5

2 a b

Liberty/LDAP Local Attributes for Assertion

PP: sn

PP: ph#

Mapped Attributes to SAML Service Provider

PP: sn = lastname

PP: ph# = phonenumber

Identity Server abc.com

c

Web Service Personal Profile (PP)

PP: sn = Jones

PP: ph# = 555-1212

1. A user is logged in to Identity Server at abc.com (the user’s identity provider) and clicks a link to xyz.com, a trusted SAML service provider.

Identity Server at abc.com generates the artifact. This starts the process of generating and sending the SAML assertion. The HREF would look similar to the following: http://nidp.com/saml/genafct?TARGET=http://xyz.com/index.html&AID=XYZ

2. Identity Server processes attributes as follows:

a. The server looks up for LDAP or Liberty-LDAP mapped attributes. (See “Mapping LDAP and Liberty Attributes” on page 477 .) In this example, you use Liberty attributes such as PP:

sn

instead of surname. PP: sn and PP: ph# are attributes that you are sending to xyz.com. b. Identity Server processes these attributes with a SAML implementation-specific attribute.

Because the identity provider must interoperate with other SAML service providers that probably do not use consistent attribute names, you can map the service provider attributes to your Liberty and LDAP attributes on Identity Server. In this example, the service provider names for the Liberty PP: sn and PP: ph# attributes are lastname and phonenumber,

respectively. (See “Configuring the Attributes Obtained at Authentication” on page 156

.) c. Identity Server uses the PP service to look up the values for the user’s PP: sn and PP: ph# attributes.

Identity Server recognizes that the values for the user’s PP: sn and PP: ph# attributes are

Jones

and 555-1212, respectively.

3. Identity Server sends an HTTP redirect with an artifact.

Identity Server now has the information to generate a SAML assertion. Identity Server sends an

HTTP redirect containing the artifact to the browser. The redirect looks similar to the following: http://xyz.com/auth/afct?TARGET=http://xyz.com/index.html&SAMLArtifact

=<<artifact>>

4. The remote SAML server requests the assertion.

The HTTP redirect results in the browser sending the artifact to the SAML server at xyz.com.

The SAML server at xyz.com requests the SAML assertion from Identity Server.

5. Identity Server sends the assertion to the remote SAML server.

420

Configuring Authentication

The remote SAML server receives the artifact and looks up the assertion.The assertion is sent to the SAML server at xyz.com in a SOAP envelope. The assertion contains the attributes

lastname=Jones

and phonenumber=555-1212.

The user now has an authenticated session at xyz.com. The xyz.com SAML server redirects the user’s browser to http://xyz.com/index.html, which was referenced in the original HREF in Step

1.

SAML Service Provider Process Flow

The following illustration provides an example of the authentication process on the consumer side, when a user clicks a link at the SAML service provider (xyz.com) to begin an authentication session with an identity provider (such as abc.com). PP indicates a Personal Profile Service as defined by the

Liberty specification.

Figure 5-21

SAML Consumer Process Flow

SAML Servicer Provider xyz.com

User/Browser

1

5

5

2

Target Resource

a b

Liberty/LDAP Local Attributes for Assertion

PP: sn

PP: ph#

Mapped Attributes to SAML Service Provider

PP: sn = lastname

PP: ph# = phonenumber

User Authentication

4

Identity Server abc.com

3 c

Web Service Personal Profile (PP)

PP: sn = Jones

PP: ph# = 555-1212

1. The user clicks a link at xyz.com.

This generates a SAML assertion intended for Identity Server at abc.com, which is the identity provider in an Access Manager configuration. After the SAML server generates the artifact, it sends the browser a redirect containing the artifact. The browser is redirected to the identity provider, which receives the artifact. The URL sent to Identity Server looks similar to the following: http://nidp.com/auth/afct?TARGET=http://abc.com/index.html&SAMLArtifact

=<<artifact>>

2. Identity Server at abc.com receives the assertion.

The assertion is sent to Identity Server packaged in a SOAP envelope. In this example, the assertion contains the attributes lastname=Jones, and phonenumber=555-1212.

3. Identity Server determines which attributes to use when locating the user.

Identity Server must determine how to locate the user in the directory. When you created the

SAML service provider reference for xyz.com, you specified which Liberty attributes must be used for this purpose. In this case, the you specified that PP: sn and PP: ph# must be used.

a. Identity Server processes the Liberty attribute map (see “Mapping LDAP and Liberty

Attributes” on page 477 ) to the SAML implementation-specific attributes (see

“Configuring the Attributes Obtained at Authentication” on page 156

).

Configuring Authentication

421

Because this SAML implementation must interoperate with other SAML implementations that probably do not use consistent attribute names, you can map the attributes used by each third-party SAML implementation to Liberty attributes on Identity Server.

b. Identity Server receives implementation-specific SAML attribute names.

The trusted service provider’s names for the Liberty PP: sn and PP: ph# attributes are returned. Using the attribute map, Identity Server knows that the service provider’s names for these attributes are lastname and phonenumber, respectively.

c. Identity Server uses the PP service to lookup the values for the user’s PP: sn and PP: ph# attributes.

Identity Server now recognizes that the values for the user’s PP: sn and PP: ph# attributes are Jones and 555-1212, respectively. The user’s DN is returned to Identity Server, and the user is authenticated.

4. The user’s DN is returned to Identity Server, and the user is authenticated.

5. The user is redirected to the target resource at xyz.com.

Configuring a SAML 2.0 Profile

You can configure the methods of communication that are available at the server for requests and responses sent between providers. These settings affect the metadata for the server and must be determined prior to publishing to other sites.

Profiles control the methods of communication that are available for SAML 2.0 protocol requests and responses sent between trusted providers. The identity provider uses the incoming metadata to determine how to respond.

All available profile bindings are enabled by default. SOAP is used when all are enabled (or if the service provider has not specified a preference), followed by HTTP Post, then HTTP Redirect.

1

In the Administration Console, click

Devices > Identity Servers > Edit > SAML 2.0 > Profiles

.

2

Configure the following fields for identity providers and identity consumers (service providers):

Artifact Resolution:

Specify whether to enable artifact resolution for the identity provider and identity consumer.

The assertion consumer service at the service provider performs a back-channel exchange with the artifact resolution service at the identity provider. Artifacts are small data objects pointing to larger SAML protocol messages. They are designed to be embedded in URLs and conveyed in

HTTP messages.

Login:

Specifies the communication channel to use when the user logs in. Select one or more of the following:

Post:

A browser-based method used when the SAML requester and responder need to communicate through an HTTP user agent. This occurs when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction to fulfill the request, such as when the user must authenticate to it.

Redirect:

A browser-based method that uses HTTP 302 redirects or HTTP GET requests to communicate requests from this identity site to the service provider. SAML messages are transmitted within URL parameters.

422

Configuring Authentication

Single Logout:

Specifies the communication channel to use when the user logs out. Select one or more of the following:

HTTP Post:

A browser-based method used when the SAML requester and responder need to communicate by using an HTTP user agent. This occurs, for example, when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction in order to fulfill the request, such as when the user must authenticate to it.

HTTP Redirect:

A browser-based method that uses HTTP 302 redirects or HTTP GET requests to communicate requests from this identity site to the service provider. SAML messages are transmitted within URL parameters.

SOAP:

Uses SOAP back channel over HTTP messaging to communicate requests from this identity provider to the service provider.

NOTE:

If

Show logged out providers

option (

Identity Servers > Edit > Identity Providers

) is enabled with HTTP Post profile, logout request from service provider does not complete.

This is due to the difference in the HTTP method used in the logout request. It is recommended to use HTTP Redirect method when

Show logged out providers option

is enabled.

Name Management:

Specifies the communication channel for sharing the common identifiers for a user between identity providers and service providers. When an identity provider has exchanged a persistent identifier for the user with a service provider, the providers share the common identifier for a length of time. When either the identity provider or service provider changes the format or value to identify the user, the system can ensure that the new format or value is properly transmitted. Select one or more of the following:

HTTP Post:

A browser-based method used when the SAML requester and responder need to communicate using an HTTP user agent. This occurs, for example, when the communicating parties do not share a direct path of communication. You also use this when the responder requires user interaction in order to fulfill the request, such as when the user must authenticate to it.

HTTP Redirect:

A browser-based method that uses HTTP 302 redirects or HTTP GET requests to communicate requests from this identity site to the service provider. SAML messages are transmitted within URL parameters.

SOAP:

Uses SOAP back channel over HTTP messaging to communicate requests from this identity provider to the service provider.

3

Click

OK

, then update Identity Server.

4

(Conditional) If you have set up trusted providers and have modified these profiles, the providers need to reimport the metadata from this Identity Server.

Creating a SAML 2.0 Service Provider

See

“Creating a Trusted Service Provider” on page 152 .

Creating a SAML 2.0 Identity Provider

See

“Creating a Trusted Identity Provider” on page 150

.

Configuring Authentication

423

Executing Authorization Based Roles Policy During SAML 2.0

Service Provider Initiated Request

Access Manager service provider federation profiles do not currently allow control based on authorization policies. Usually the service providers enforce authorization rules. However, not all service providers have this flexibility. It is recommended not to trust the service provider to enforce such rules. You can now apply an authorization policy to a configured service provider to either allow or not to allow access to the service provider. Identity Server will evaluate the service provider and will generate the successful/unsuccessful assertions.

Use Case:

Company xyz.com uses a CRM application that is protected through the SAML 2.0 service provider. This application must only be accessible to the sales team and not to any other teams. Whenever a user accesses the application through the service provider, it redirects to Identity

Server for validating the user.

Figure 5-22

Executing Authorization Policy Based on Role

Identity Server must authenticate the user and then check if the user is a member of the sales team.

If yes, Identity Server sends a successful assertion to the service provider. Else, Identity Server sends an error response to the service provider.

By default, Identity Server executes these authorization policies after a user is authenticated during spsend. Set the ALLOW_AUTH_POLICY_EXECUTION option to false to disable Identity Server to execute

the authorization policies. For information about how to set this option, see “Configuring Identity

Server Global Options” on page 57 .

If the authorization policy is to deny execution, Identity Server sends the following message as part of an assertion response. <samlp:Status> <samlp:StatusCode

Value="urn:oasis:names:tc:SAML:2.0:status:Responder">

<samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" /> </ samlp:StatusCode> <StatusMessage>Authorization is failed</StatusMessage> </ samlp:Status>

424

Configuring Authentication

For more information about configuring a brokering for authorization of service providers, see

“Configuring a Brokering for Authorization of Service Providers” on page 404 .

Contracts Assigned to a SAML 2.0 Service Provider

During federation, when a service provider initiates an authentication request, contract information may not be available. If the contract information is not available, Identity Server executes a default contract for validating the user. The step up authentication feature enables you to assign a default contract for service providers in such scenarios.

The following scenario helps you understand the execution of contracts that are assigned to the

SAML 2.0 service provider.

Figure 5-23

Step Up Authentication example with two applications:

There are two applications Payroll and HR web applications protected through different service providers and are using Access Manager Identity Server as identity provider. The user wants to use the name/password form contract whenever the user accesses the HR application and wants to use the higher level contract say X509 for the Payroll application. Identity Server provides ability to execute the appropriate contract that has been assigned to the service provider instead of executing the default contract.

The following procedure allows you to assign a specific contract to the service provider.

1

Click on

Devices > Identity Servers > Edit > > SAML2.0

.

2

Click on configured service provider.

3

Go to

Options

>

Step Up Authentication

contracts and select the contracts from the

Available contracts

list.

The following table lists the behavior of a service provider request.

Configuring Authentication

425

Service Provider Request Result (Identity Server Response if the user is not authenticated)

Service provider request has no contract information to be executed at Identity Server.

1. Identity Server has no contracts set for this service provider as in

Step 3 .

Execute default contract for validating the user and default contract name will be sent in the response.

2. Identity Server has contract C1 set for this service provider as in

Step 3 .

C1 will be executed for validating the user and C1 will be sent in response.

Service provider requests execution of contract C1 at Identity Server.

1. Identity Server has no contracts set for this service provider as in

Step 3 .

C1 will be executed for validating the user and C1 will be sent in response.

2. Identity Server has contract C1 set for this service provider as in

Step 3 .

3. Identity Server has contract C2 set for this service provider. C2 has trust level check disabled.

C1 will be executed for validating the user and C1 will be sent in response.

4. Identity Server has contract C2 set for this service provider. C2 has trust level check enabled.

C2 will be executed for validating the user and C2 will be sent in response. (Note: This is as good as C1 not available at Identity Server)

If trust level of C2 >= trust level of C1, then C2 will be executed and C2 will be sent in response.

If trust level of C2 < trust level of C1, then C1 will be executed and C1 will be sent in response.

If C1 is not available at Identity Server, then C2 is executed and C2 is sent in the response.

NOTE:

When using the service provider (SP) initiated login with a SAML 2.0 SP federation, the SP configuration can impact the selection of the Access Manager contract for authentication depending on the values sent in SAML authentication request. To make it work properly, you must define your

Access Manager contract URI to match with the request sent by the service provider.

For more information, see “Allowable Class” in

“Configuring Authentication Contracts” on page 289

.

Configuring Communication Security for a SAML 2.0 Identity Provider

The security settings control the direct communication between Identity Server and the identity provider across the SOAP back channel.

1

In the Administration Console, click

Devices > Identity Servers > Edit

>

SAML 2.0

.

2

Click the name of an identity provider.

3

On the Trust page, fill in the following fields:

Name:

Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider.

The

Security

section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method.

Encrypt name identifiers:

Specifies whether you want the name identifiers encrypted on the wire.

426

Configuring Authentication

Select one of the following security methods:

Message Signing:

Relies upon message signing using a digital signature.

Mutual SSL:

Specifies that this trusted provider provides a digital certificate (mutual SSL) when it sends a SOAP message.

SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the server’s certificate authority

(CA) certificate must be imported into the client trust store. For the server to trust the client, the client’s CA certificate must be imported into the server trust store.

Basic Authentication:

Specifies standard header-based authentication. This method assumes that a name and password for authentication are sent and received over the

SOAP back channel.

Send:

The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon.

Verify:

The name and password used to verify data that the trusted provider sends.

Certificate Revocation Check Periodicity:

Specifies if the certificate is valid or not. You can define periodicity to validate on start up, on assertion level, or set frequency to hourly/ daily.

4

Click

OK

twice.

5

Update Identity Server.

Configuring Communication Security for a SAML 2.0 Service Provider

The security settings control the direct communication between Identity Server and the service provider across the SOAP back channel.

1

In the Administration Console, click

Devices > Identity Servers > Edit

>

SAML 2.0

.

2

Click the name of a service provider.

3

On the Trust page, fill in the following fields:

Name:

Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider.

The

Security

section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method.

Encrypt assertions:

Specifies whether you want the assertions encrypted on the wire.

Encrypt name identifiers:

Specifies whether you want the name identifiers encrypted on the wire.

SOAP Back Channel Security Method:

Select one of the following security methods.

Message Signing:

Relies upon message signing using a digital signature.

Mutual SSL:

Specifies that this trusted provider provides a digital certificate (mutual SSL) when it sends a SOAP message.

SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the server’s certificate authority

(CA) certificate must be imported into the client trust store. For the server to trust the client, the client’s CA certificate must be imported into the server trust store.

Basic Authentication:

Specifies standard header-based authentication. This method assumes that a name and password for authentication are sent and received over the

SOAP back channel.

Configuring Authentication

427

Send:

The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon.

Verify:

The name and password used to verify data that the trusted provider sends.

4

Click

OK

twice.

5

Update Identity Server.

Editing a SAML 2.0 Service Provider’s Metadata

See

“Editing a SAML 2.0 Service Provider’s Metadata” on page 159

.

Configuring a SAML 2.0 Authentication Request

You can configure how an authentication request is federated. When users authenticate to a service provider, they can be given the option to federate their account identities with the preferred identity provider. This process creates an account association between the identity provider and service provider that enables single sign-on and single log-out.

The authentication request specifies how you want the identity provider to handle the authentication process so that it meets the security needs of Identity Server.

1

In the Administration Console, click

Devices > Identity Servers > Edit > SAML 2.0 > [Identity

Provider] > Authentication Card

>

Authentication Request.

2

Configure the name identifier format:

Persistent:

A persistent identifier federates the user profile on the identity provider with the user profile on the service provider. It remains intact between sessions.

The persistent identifier is saved to the user data store and hides the user’s identity to prevent tracking of user activities across different relying parties.

After authentication:

Specifies that the persistent identifier can be sent after the user has authenticated (logged in) to the service provider. When you set only this option, users must log in locally. Because the user is required to authenticate locally, you do not need to set up user identification.

During authentication:

Specifies that the persistent identifier can be sent when the user selects the authentication card of the identity provider. Typically, a user is not authenticated at the service provider when this selection is made. When the identity provider sends a response to the service provider, the user needs to be identified on the service provider. If you enable this option, ensure that you configure a user identification method. See

“Selecting a User Identification Method for Liberty or SAML 2.0” on page 417 .

Transient:

Specifies that a transient identifier, which expires between sessions, can be sent.

Unspecified:

Allows either a persistent or a transient identifier to be sent.

3

Select one of the following options for the

Requested By

option:

Do not specify:

Specifies that the identity provider can send any type of authentication to satisfy a service provider’s request, and instructs a service provider to not send a request for a specific authentication type or contract.

Use Types:

Specifies that authentication types must be used.

Select the type of comparison (for more information, see “Understanding Comparison Contexts” on page 436 ):

Exact:

Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.

428

Configuring Authentication

Minimum:

Indicates that the contract must be as strong as the class or type specified in the authentication statement.

Better:

Indicates the contract that must be stronger than the class or type specified in the authentication statement.

Maximum:

Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.

Select the types from the

Available types

field to specify which type to use for authentication between trusted service providers and identity providers. Standard types include Name/

Password, X.509, Token, and so on.

Use Contracts:

Specifies that authentication contracts must be used.

Select the type of comparison (for more information, see “Understanding Comparison Contexts” on page 436 ):

Exact:

Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.

Minimum:

Indicates that the contract must be as strong as the class or type specified in the authentication statement.

Better:

Indicates the contract that must be stronger than the class or type specified in the authentication statement.

Maximum:

Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.

Select the contract from the

Available contracts

list. For a contract to appear in the

Available contracts

list, the contract must have the

Satisfiable by External Provider

option enabled. To use the contract for federated authentication, the contract’s URI must be the same on the identity

provider and the service provider. For information about contract options, see “Configuring

Authentication Contracts” on page 289

.

Most third-party identity providers do not support contracts.

4

Configure the options:

Response protocol binding:

Select

Artifact

or

Post

or

Let IDP Decide

. Artifact and Post are the two methods for transmitting assertions between the authenticating system and the target system.

If you select

Let IDP Decide

, the binding is selected based on the profile that is enabled at

Identity Provider and the binding selected in the service provider.

NOTE:

The post binding can be configured to be sent as a compressed option. Perform the following steps to achieve this:

1. In the Administration Console, click

Devices > Identity Servers > Edit

>

Options

>

New

.

2. Select

IS SAML2 POST INFLATE

in

Property Type

and

true

in

Property Value

.

3. Click

OK

.

4. Click

Devices > Identity Servers > Edit > SAML 2.0 > Service Provider

or

Identity Provider

>

Options

>

New

.

5. Select

SAML2 POST DEFLATE TRUSTEDPROVIDERS

in

Property Type

and

enter

trusted providerʹs name, metadata URI, or provider ID in

Property Value

. You can specify multiple trusted providers in a comma separated format. These are the trusted providers who expect

SAML2 POST messages in deflated format. In other words, this provider has to send deflated SAML2 POST messages to the listed trusted providers.

6. Click

OK

.

7. Restart Identity Server by using this command: /etc/init.d/novell-idp restart.

Configuring Authentication

429

Allowable IDP proxy indirections:

Specifies whether the trusted identity provider can proxy the authentication request to another identity provider. A value of

None

specifies that the trusted identity provider cannot redirect an authentication request. Values 1-5 determine the number of times the request can be proxied. Select

Let IDP Decide

to let the trusted identity provider decide how many times the request can be proxied

Force authentication at Identity Provider:

Specifies that the trusted identity provider must prompt users for authentication, even if they are already logged in.

Use automatic introduction:

Attempts single sign-on to this trusted identity provider by automatically sending a passive authentication request to the identity provider. (A passive requests does not prompt for credentials.) The identity provider sends one of the following authentication responses:

When the federated user is authenticated at the identity provider:

The identity provider returns an authentication response indicating that the user is authenticated. The user gains access to the service provider without entering credentials (single sign-on).

When the federated user is not authenticated at the identity provider:

The identity provider returns an authentication response indicating that the user is not logged in. The user can then select a card for authentication, including the card for the identity provider. If the user selects the identity provider card, an authentication request is sent to the identity provider. If the credentials are valid, the user is also authenticated to the service provider.

IMPORTANT:

Enable the

Use automatic introduction

option only when you are confident the identity provider will be up. If the server is down and does not respond to the authentication request, the user gets a page-cannot-be-displayed error. Local authentication is disabled because the browser is never redirected to the login page.

This option must be enabled only when you know the identity provider is available 99.999% of the time or when the service provider is dependent upon this identity provider for authentication.

5

Click

OK

twice, then update Identity Server.

Understanding Comparison Contexts

When a service provider makes a request for an identity provider to authenticate a user, the authentication request can contain a class or type and a comparison context. The identity provider uses these to determine which authentication procedure to execute. There are four comparison contexts:

Exact:

Indicates that the class or type specified in the authentication statement must be an exact match to at least one contract.

For example, when the comparison context is set to exact, the identity provider uses the URI in the request to find an authentication procedure. If an exact URI match is found, the user is prompted for the appropriate credentials. If an exact match is not found, the user is denied access.

Better:

Indicates the contract that must be stronger than the class or type specified in the authentication statement.

If the identity provider is a NetIQ Identity Server, Identity Server first finds the specified class or type and its assigned authentication level. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for the class or type, the identity provider looks for a contract with an authentication level that is higher than 1. If one is found, the user is prompted for the appropriate credentials. If more than one is found, the user is presented with the matching cards and is allowed to select the contract. If a match is not found, the user is denied access.

430

Configuring Authentication

Minimum:

Indicates that the contract must be as strong as the class or type specified in the authentication statement.

If the identity provider is a NetIQ Identity Server, Identity Server first finds the specified class or type and its assigned authentication level. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for the class or type, the identity provider looks for a contract with an authentication level of 1 or higher. If one is found, the user is prompted for the appropriate credentials. If more than one is found, the user is presented with the matching cards and is allowed to select the contract. If a match is not found, the user is denied access.

Maximum:

Indicates that contract must as strong as possible without exceeding the strength of at least one of the authentication contexts specified.

If the identity provider is a NetIQ Identity Server, Identity Server first finds the specified classes or types and their assigned authentication levels. It then uses this information to find a contract that matches the conditions. For example if the authentication level is set to 1 for some types and 3 for other types, the identity provider looks for contracts with an authentication level of 3. If a match or matches are found, the user is presented with the appropriate login prompts. If there are no contracts defined with a authentication level of 3, the identity provider looks for a match with an authentication level of 2, or if necessary, level 1. It cannot search below the lowest level of class in the authentication request or higher than the highest level of a class in the authentication request.

When you configure the authentication request, you specify the comparison context for a type or a contract.

Configuring the SAML 2.0 Authentication Response

After you create a trusted service provider, you can configure how your Identity Server responds to authentication requests from the service provider.

1

In the Administration Console, click

Devices > Identity Servers > Edit > SAML 2.0 > [Service

Provider] > Authentication Response

.

2

Select the binding method.

If the request from the service provider does not specify a response binding, you need to specify a binding method to use in the response. Select

Artifact

to provide an increased level of security by using a back-channel means of communication between the two servers. Select

Post

to use

HTTP redirection for the communication channel between the two servers. If you select

Post

, you might want to require the signing of the authentication requests. See

“Configuring the

General Identity Provider Settings” on page 146

.

NOTE:

The post binding can be configured to be sent as a compressed option. Perform the following steps to achieve this:

1. In the Administration Console, click

Devices > Identity Servers > Edit

>

Options

>

New

.

2. Select

IS SAML2 POST INFLATE

in

Property Type

and

true

in

Property Value

. This provider will receive deflated SAML2 POST messages from its trusted providers.

3. Click

OK

.

4. Click

Devices > Identity Servers > Edit > SAML 2.0 > Service Provider

or

Identity Provider

>

Options

>

New

.

Configuring Authentication

431

5. Select

SAML2 POST DEFLATE TRUSTEDPROVIDERS

in

Property Type

and

enter

trusted providerʹs name, metadata URI, or provider ID in

Property Value

. You can specify multiple trusted providers in a comma separated format. These are the trusted providers who expect

SAML2 POST messages in deflated format. In other words, this provider has to send deflated SAML2 POST messages to the listed trusted providers.

6. Click

OK

.

7. Restart Identity Server by using this command: /etc/init.d/novell-idp restart.

3

Specify the identity formats that Identity Server can send in its response. Select the box to choose one or more of the following:

Persistent:

Specifies that a persistent identifier, which is written to the directory and remains intact between sessions, can be sent.

Transient:

Specifies that a transient identifier, which expires between sessions, can be sent.

E-mail:

Specifies that an e-mail attribute can be used as the identifier.

Kerberos:

Specifies that a Kerberos token can be used as the identifier.

X509:

Specifies that an X.509 certificate can be used as the identifier.

Unspecified:

Specifies that an unspecified format can be used and any value can be used.

The service provider and the identity provider need to agree on the value that is placed in this identifier.

4

Use the

Default

button to select the name identifier that Identity Server must send if the service provider does not specify a format.

If you select E-mail, Kerberos, x509, or unspecified as the default format, you must also select a value. See

Step 5 .

IMPORTANT:

If you have configured the identity provider to allow a user matching expression to fail and still allow authentication by selecting the

Do nothing

option, you need to select

Transient identifier format

as the default value. Otherwise the users who fail the matching expression are

denied access. To view the identity provider configuration, see “Defining User Identification for

Liberty and SAML 2.0” on page 416 .

5

Specify the value for the name identifier.

The persistent and transient formats are generated automatically. For the others, you can select an attribute. The available attributes depend upon the attributes that you have selected to send

with authentication (see “Configuring the Attributes Obtained at Authentication” on page 156

). If you do not select a value for the E-mail, Kerberos, X509, or Unspecified format, a unique value is automatically generated.

6

To specify that this Identity Server must authenticate the user, disable the

Use proxied requests

option. When the option is disabled and Identity Server cannot authenticate the user, the user is denied access.

When this option is enabled, Identity Server checks to see if other identity providers can satisfy the request. If one or more can, the user is allowed to select which identity provider performs the authentication. If a proxied identity provider performs the authentication, it sends the response to

Identity Server. Identity Server then sends the response to the service provider.

7

Click

OK

twice, then update Identity Server.

432

Configuring Authentication

Defining Options for SAML 2.0

OIOSAML enables service providers to use external authentication services, implements single signon across disparate systems, and establishes a foundation for federated identity management.

OIOSAML enables reuse of authentication services and consistent application of security technology.

You can implement the Single Logout Profile of OIOSAML. This profile enables you to logout from all service providers whose session originate from a particular identity provider. For using this profile, you must use a front channel binding.

This section includes the following topics:

“Defining Options for a SAML 2.0 Identity Provider” on page 438

“Defining Options for a SAML 2.0 Service Provider” on page 441

Defining Options for a SAML 2.0 Identity Provider

1

In Administration Console, click

Devices > Identity Servers > Servers > Edit > SAML 2.0 >

Identity Provider

>

Options

.

2

Select the required options:

OIOSAML Compliance:

Select this option to make the identity provider OIOSAML compliant.

Enable Front Channel Logout:

Select this option to enable a enable a service provider to initiates a logout at the identity provider by using the HTTP Redirect method.

3

Click

New

to set SAML properties for an identity provider. The following table lists the available properties:

NOTE:

Access Manager 4.2 onwards, configuring the following options through files is deprecated. You must configure these option by using the Administration Console.

Configuring Authentication

433

Property Type Property Value

Extensions

SAML ASSERTION INCLUDE

MILLISECS

SAML2 ATTRIBUTE CONSUMING

INDEX

SAML2 AVOID CONSENT

SAML2 AVOID ISPASSIVE

SAML2 AVOID NAMEIDPOLICY

SAML2 AVOID PROTOCOLBINDING

SAML2 AVOID PROXYCOUNT

SAML2 AVOID SIGN AND VALIDATE

ASSERTIONS TRUSTED PROVIDERS

SAML2 CHANGE ISSUER

Specify the value in this format: <samlp:Extensions>. This value is sent in the authentication request to this identity provider.

Select true to get SAML requests for this identity provider including the timestamp in millisecond in IssueInstant.

Select the value of AttributeConsumingServiceIndex in SAML requests to this identity provider from the specified integer value.

Select true to not include Consent as part of the SAML 2.0 request to this identity provider.

If you select true, IsPassive is not included in SAML 2.0 request to this identity provider.

If you select true, NameIDPolicy is not included in a SAML 2.0 request to this identity provider.

If you select true, ProtocolBinding is not included in a SAML

2.0 request to this identity provider.

If you select true, ProxyCount is not included in a SAML 2.0 request to this identity provider.

If you select true, the cluster will accept SAML 2.0 POST responses from this provider when the response is signed and assertion is not.

Specify the provider ID to be sent as issuer in the SAML requests to this identity provider.

The value is in format {SPProviderID}->{issuer name}.

{SPProviderID} will be replaced by the actual provider ID of the service provider. This will set the issuer of SAML 2.0 requests to the issuer name specified here.

For example, https://nam.rtreyresearch.net:8443/nidp/saml2/ metadata->https://saml.mariagerfjord.dk:8443/nidp/saml2/ metadata.

SAML2 POST DEFLATE

TRUSTEDPROVIDERS

SAML2 SEND ACS INDEX

If you select true, the cluster will send deflated post messages to this provider.

Select true to send AssertionConsumerServiceIndex with

AuthnRequest to this identity provider.

SAML2 SEND ACS URL Select true to send AssertionConsumerServiceURL with

AuthnRequest to this identity provider.

SAML2 SIGN METHODDIGEST SHA256 Set the value to true to use SHA256 algorithm as signing algorithm for assertions.

OTHER Specify Property Name and Value if you want to configure any other property for this identity provider.

4

Click

OK

>

Apply

.

434

Configuring Authentication

Sample XML File When All SAML Options Are Set to True

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" AssertionConsumerServiceIndex="2"

ForceAuthn="false" ID="id5R6u1JFtay7eK.il97Q3eRl34u8" IssueInstant="2013-01-18T06:11:26Z"

Version="2.0">

<saml:Issuer> https://nam.rtreyresearch.net:8443/nidp/saml2/metadata</saml:Issuer >

</samlp:AuthnRequest>

Sample XML File When All SAML Options Are Set to False

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"xmlns:saml="urn:oasis:names:tc:SAML:2.0:as sertion" AssertionConsumerServiceIndex="0"

AttributeConsumingServiceIndex

="2"Consent="urn:oasis:names:tc:SAML:2.0:consent:unavailabl e" ForceAuthn="false" ID="idoeZTKq7FOs5MsCigBBCwp30lqD0"

IsPassive

="false"IssueInstant="2013-01-

23T05:25:32Z"ProtocolBindingProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-

POST"Version="2.0">

<saml:Issuer> https://saml.mariagerfjord.dk:8443/nidp/saml2/metadata</saml:Issuer >

<samlp:NameIDPolicyAllowCreate="true"Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent"SPNameQualifier="https://nam.rtreyresearch.net:8443/nidp/saml2/metadata"/

><samlp:Scoping ProxyCount="5"/>

</samlp:AuthnRequest>

Defining Options for a SAML 2.0 Service Provider

You can use Access Manager as an identity provider for several service providers.You can configure a specific authentication contract that is required for a service provider. If you have configured more than one authentication contract for a service provider, the contract with minimum level is selected.

When providing authentication to a service provider, Identity Server ensures that the user is authenticated by the required contract. When a user is not authenticated or when a user is authenticated, but the authenticated contracts do not satisfy the required contracts, user is prompted to authenticate with the required contract. This is called step up authentication.

If no required contract is configured, then the default contract is executed.

NOTE:

For SAML 2.0, this step up authentication is supported for Intersite Transfer Service (for both identity provider initiated and service provider initiated requests). For Liberty, it works only for identity provider initiated requests.

Perform the following steps to define options for a SAML 2.0 service provider:

1

In Administration Console, click

Devices > Identity Servers > Servers > Edit > SAML 2.0 >

Service Provider

>

Options

.

2

Select

OIOSAML Compliance

to make the service provider OIOSAML compliant. The OIOSAML attribute set is automatically populated with the required attributes to send with authentication after selecting this check box.

3

Select the required step up authentication contracts from the

Available contracts

list and move them to the

Selected contracts

list. This is to provide the step up authentication for the service provider.

Configuring Authentication

435

NOTE:

Only the contract that is configured first in the

Selected contracts

list will be executed.

This is applicable only for SAML 2.0.

4

Click

New

to set SAML properties for a service provider. The following table lists the available properties:

NOTE:

Access Manager 4.2 onwards, configuring the following options through files is deprecated. You must configure these option by using the Administration Console.

Property Type Description

SAML ASSERTION INCLUDE MILLISECS

SAML2 AVOID AUDIENCE RESTRICTION

SAML2 AVOID CONSENT

SAML2 AVOID SIGN AND VALIDATE

ASSERTIONS TRUSTED PROVIDERS

SAML2 AVOID SPNAMEQUALIFIER

SAML2 AVOID SPNAMEQUALIFIER TO

Select true to get SAML responses for this service provider including the timestamp in millisecond in

IssueInstant.

Select true to avoid sending the audience restriction information with assertion to this service provider.

Select true to not include Consent as part of the

SAML 2.0 request.

If you select true, the cluster will sign SAML 2.0

POST responses (excluding the assertion) for this provider.

Select true to not include SPNAMEQUALIFIER in

NAMEIDENTIFER

in the assertion.

Select true to send SPNAMEQUALIFIER in

NAMEIDENTIFER with the assertion.

SAML2 NAMEID ATTRIBUTE NAME Specify the LDAP attribute name that will be sent in the name identifier in a SAML response for this service provider.

SAML2 POST DEFLATE TRUSTEDPROVIDERS If you select true, the cluster will send deflated post messages to this provider.

SAML2 POST SIGN RESPONSE

TRUSTEDPROVIDERS

SAML2 REQUEST IGNORE AUTHCONTEXT

If you select true, the identity provider will sign the entire SAML 2.0 response for this service provider.

If you select true, the identity provider ignores any specific authentication available in a SAML request from this service provider.

SAML2 SIGN METHODDIGEST SHA256

OTHER

If you select true, assertion will use the SHA 256 algorithm as a hashing algorithm for this service provider.

Specify Property Name and Value if you want to configure any other property for this service provider.

5

Click

OK

>

Apply

.

436

Configuring Authentication

Defining Session Synchronization for the A-Select SAML 2.0 Identity

Provider

If a user session is active on the service provider, the service provider periodically sends session synchronization to Identity Server to maintain the session. You must configure the properties for the session synchronization between the service provider and the target identity provider.

1

In the Administration Console, click

Devices > Identity Servers > Servers > Edit > Liberty or

SAML 2.0 > Identity Provider

>

Options.

2

Click

New

.

3

Select

Other

in

Property Type

.

4

Specify the following values:

Property Name

: config.aselect.sessionsync.enabled

Property Value

: true

5

For session synchronization, add two options, one to enable the session synchronization and the other to provide the URL to which synchronization message must be sent.

The session synchronization message is sent from the Access Manager service provider to the

A-Select identity provider, in tandem with the Access Gateway ESP's activity update. The session synchronization message is sent only if the user session is active at the Access

Gateway portal, which is the ESP to the Access Manager service provider. If you log in directly to the Access Manager service provider, even if the session is active, the session synchronization message is not sent to the A-Select identity provider.

6

Click

OK,

then update Identity Server.

Configuring the Liberty or SAML 2.0 Session Timeout

When you are active on a session on the service provider and a timeout occurs, the service provider initiates a logout.You can configure this timeout by using the web.xml parameter in the Access

Gateway ESP, then ESP initiates a logout message to the Access Manager service provider over the

SOAP back channel when the timeout is reached. After the service provider receives this message, it creates a SAML 2.0 logout request to the remote identity provider over SOAP.

To send session timeout message:

1

In the Administration Console, click

Devices

>

Access Gateways

>

Edit

>

Reverse Proxy /

Authentication

>

ESP Global Options

.

2

Remove the pound (#) symbol before notifysessionTimetoIDP and set the value as true.

ESP sends a ESP session timeout message. After timeout, the service provider sends a samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol request to the remote identity provider.

3

Restart Tomcat on each Identity Server in the cluster by using the following command:

/etc/init.d/novell-idp restart

Session Termination

If you set the session synchronization between the Service Provider and remote Identity Provider, then the remote Identity Provider never sends the logout request to the active Service Provider.

Configuring Authentication

437

Modifying the Authentication Card for Liberty or SAML 2.0

When you create an identity provider, you must also configure an authentication card. After it is created, you can modify it.

1

In the Administration Console, click

Devices > Identity Servers > Edit > [Protocol] > [Identity

Provider] > Authentication Card.

2

Modify the values in one or more of the following fields:

ID:

If you have need to reference this card outside of the user interface, specify an alphanumeric value here. If you do not assign a value, Identity Server creates one for its internal use. The internal value is not persistent. Whenever Identity Server is rebooted, it can change. A specified value is persistent.

Text:

Specify the text that is displayed on the card to the user. This value, in combination with the image, must identify to the users, which provider they are logging into.

Image:

Specify the image to be displayed on the card. Select the image from the drop-down list.

To add an image to the list, click

<Select local image>

.

Show Card:

Determine whether the card is shown to the user, which allows the user to select and use the card for authentication. If this option is not selected, the card is only used when a service provider makes a request for the card.

NOTE:

Do not disable the

Show Card

option for default contracts.

Passive Authentication Only:

Select this option if you do not want Identity Server to prompt the user for credentials. If Identity Server can fulfill the authentication request without any user interaction, the authentication succeeds. Otherwise, it fails.

Satisfies Contract:

Select the required contracts from the

Available contracts

list and move them to the

Satisfies contract

list.

If Access Manager Identity provider is unable to execute the requested authentication contract, it looks for the configured external Identity provider. This happens when

Satisfiable by External

Contract

option is enabled which satisfies the incoming authentication (contract) request. If the match is found, Identity provider lists all the satisfiable contracts to select the appropriate contract. If only a single match is found, Identity provider redirects it to an external contract.

If the local Identity Provider is able to authenticate using a local contract, which is satisfiable by an external provider, then the preference is first given to the local contract along with the other authentication cards also listed.

To configure the contract matching criteria, see Allowable Class

in “Configuring Authentication

Contracts” on page 289

.

3

Click

OK

twice, then update Identity Server.

438

Configuring Authentication

Configuring Multiple SAML 2.0 Service Providers on the Same Host for a Single SAML Identity Provider

When the same Access Manager server hosts more than one SAML service provider and federate with another Access Manager acting as an identity provider for these service providers, Access

Manager must send different sets of attributes in SAML 2.0 assertions to these service providers.

Perform the following steps to create multiple service providers on the same Access Manager host:

1

To create multiple service providers from the same identity provider metadata, manually modify the identity provider's metadata's entityID for each service provider. You can import the metadata text that was edited into the Access Manager configuration to create service providers with different entity IDs.

For more information about how to create a SAML 2.0 service provider, see “Creating a Trusted

Service Provider” on page 152 .

2

In the Administration Console of the SAML 2.0 identity provider, click

Devices

>

Identity Servers

>

Servers

>

Edit

>

SAML 2.0

>

Service Provider

>

Options

>

New

.

3

Set the SAML2 AVOID AUDIENCE RESTRICTION property to true. Setting this property to true avoids audience restriction in the SAML 2.0 assertion.

4

To avoid the spnamequalifier attribute in nameidentifier of the assertion, do the following:

4a

In Administration Console of the SAML 2.0 service provider, click

Devices

>

Identity

Servers

>

Servers

>

Edit

>

SAML 2.0

>

Service Provider

>

Options

>

New.

4b

Set the SAML2 AVOID SPNAMEQUALIFIER TO property to true.

4c

Click

OK

.

5

Restart Identity Server.

NOTE:

This is possible only when the identity provider and service providers are deployed on Access

Manager.

Configuring Active Directory Federation Services with SAML 2.0 for

Single Sign-On

This section describes step-by-step instructions for configuring a basic identity federation deployment between Microsoft Active Directory Federation Services 2.0 (AD FS 2.0) and Access Manager by using the Security Assertion Markup Language (SAML) 2.0 protocol, specifically its Web Browser

SSO Profile and HTTP POST binding.

You can configure AD FS 2.0 as the claims provider and Access Manager as the relying party, or you can configure Access Manager as the claims provider and AD FS 2.0 as the relying party or service provider.

“Prerequisites and Requirements” on page 446

“Configuring Access Manager as a Claims or Identity Provider and AD FS 2.0 as Relying Party or Service Provider” on page 447

“Configuring AD FS 2.0 as the Claims or Identity Provider and Access Manager as the Relying

Party or Service Provider” on page 454

“AD FS 2.0 Basics” on page 457

“Debugging AD FS 2.0” on page 458

Configuring Authentication

439

Prerequisites and Requirements

Two servers, one to host AD FS 2.0 and the other to host Access Manager.

AD FS 2.0 is deployed.

ADFS 2.0 with WIF is deployed.

The test deployment that was created in the AD FS 2.0 Federation with a Windows Identity

Foundation (WIF) (http://go.microsoft.com/fwlink/?LinkId=193997) application is used as starting point for this deployment. A single Windows Server 2012 instance (fsweb.contoso.com) is used to host both the AD FS 2.0 federation server and a WIF sample application. It presumes the availability of a Contoso.com domain, in which fsweb.contoso.com is a member server. The same computer can act as the domain controller and federation server in the test deployments.

ADFS 2.0 with SharePoint 2010 is deployed.

The test deployment that was created in the Configuring SharePoint 2010 AAM applications with

AD FS 2.0 (http://technet.microsoft.com/en-us/library/gg295319.aspx) is used as starting point for this deployment. A single Windows Server 2012 instance (fsweb.contoso.com) is used to host the AD FS 2.0 federation server and a Windows Server 2012 instance (SP2010) is used to host the SharePoint 2010 application. It presumes the availability of a Contoso.com domain, in which fsweb.contoso.com is a member server. The same computer can act as the domain controller and federation server in the test deployments.

Access Manager is deployed.

The Access Manager environment in this deployment is hosted by a fictitious company called nam.example.com. Only Identity Server component of Access Manager is required for this federation. For more information about installation and deployment of Access Manager, see

NetIQ Access Manager Appliance 4.2 Installation and Upgrade Guide .

NOTE:

You can download the evaluation version of Access Manager from NetIQ’s download portal .

Environment

Access Manager 4.x.x.

SUSE Linux Enterprise Server (SLES) 11 SP4 64-bit or a higher version.

IP Connectivity

Ensure that the Access Manager (nam.example.com) and AD FS 2.0 (fsweb.contoso.com) systems have IP connectivity between them. The Contoso.com domain controller, if it is running on a separate computer, does not require IP connectivity to the Access Manager system. If the Access Manager firewall is set up, open the ports required for Identity Server to communicate with the Administration

Console.

For more information about these ports, see “ Setting Up Firewalls ” in the

NetIQ Access Manager

Appliance 4.2 Installation and Upgrade Guide

.

For HTTPS communication, the Access Manager Identity Server uses TCP 8443 by default. Your browsers need to access this port when using the HTTP POST Binding. Or, you can change this port to 443 by using iptables.

For back-channel communication with cluster members, you need to open two consecutive ports for

the cluster, such as 7801 and 7802. The initial port (7801) is configurable. See “Configuring a Cluster with Multiple Identity Servers” on page 55 .

All federation servers (AD FS and Access Manager) need access to a reliable Network Time Protocol

(NTP) time source.

440

Configuring Authentication

Name Resolution

The hosts file on the AD FS 2.0 computer (fsweb.contoso.com) is used to configure name resolution of the partner federation servers and sample applications.

Clock Synchronization

Federation events have a short time to live (TTL). To avoid errors based on time-outs, ensure that both computers have their clocks synchronized.

NOTE:

On SLES 11 SP1 64-bit or a higher version, use the command sntp -P no -p pool.ntp.org

to synchronize time with the Internet time server.

Configuring Access Manager as a Claims or Identity Provider and AD FS 2.0 as

Relying Party or Service Provider

This section explains how to configure a setup in which an Access Manager user gets federated access to the WIF sample application or SharePoint 2010 through AD FS 2.0. This setup uses the

SAML 2.0 POST profile.

“Configuring Access Manager” on page 447

“Configuring AD FS 2.0” on page 449

“Example Scenario: Access Manager as the Claims Provider and AD FS 2.0 as the Relying

Party” on page 453

Configuring Access Manager

Using Metadata to Add a New Service Provider Connection

Exporting the Identity Provider Metadata to a File

NOTE:

To deploy this identity federation, create a new contract with the

“urn:oasis:names:tc:SAML:2.0:ac:classes:Password” URI and with the name password form method.

Configure this contract as the default contract.

Using Metadata to Add a New Service Provider Connection

The first step in configuring Access Manager is to use the AD FS metadata to add a service provider for Access Manager.

Getting the AD FS 2.0 Metadata

Using the Metadata to Add a New Service Provider Connection

Adding an AD FS Server Trusted Certificate

Creating an Attribute Set in Access Manager

Configuring the Service Provider in Access Manager

Getting the AD FS 2.0 Metadata

1

Access the AD FS server metadata URL at https://<<ADFS (hostname or IP)/

FederationMetadata/2007-06/FederationMetadata.xml.

2

Save the AD FS metadata file.

3

Open the saved AD FS metadata file in Notepad, WordPad, or in any XML editor.

Configuring Authentication

441

4

Remove the <RoleDescriptor> tags from the metadata. For example, remove the following tags:

<RoleDescriptor xsi:type="fed:ApplicationServiceType" protocolSupportEnumeration=http://..................... ……> ……….</

RoleDescriptor>

<RoleDescriptor xsi:type="fed:SecurityTokenServiceType" protocolSupportEnumeration=http://..... ………> </RoleDescriptor>

5

Save the changes.

Using the Metadata to Add a New Service Provider Connection

1

In the Access Manager Administration Console, click

Devices

>

Identity Server

>

Edit

>

SAML

2.0

.

2

Click

New

>

Add Service Provider

.

3

In the

Name

field, specify a name by which you want to refer to the provider.

4

Select

Metadata Text

from the

Source

list.

5

Paste the copied AD FS metadata that you saved in

Step 5 on page 448 into the

Text

field.

6

Click

Next

>

Finish

.

7

Update Identity Server.

Adding an AD FS Server Trusted Certificate

1

Download the certificate authority (CA) certificate from the AD FS server.

2

In the Access Manager Administration Console, click

Security

>

Certificates

>

Trusted Roots

.

3

Click

Import

.

4

Specify a name for the certificate and browse for the ADFS certificate.

5

Click

OK

.

6

Click

Uploaded AD FS CA

.

7

Click

Add to Trusted Store

and select

config store

.

8

Update Identity Server.

Creating an Attribute Set in Access Manager

1

In the Access Manager Administration Console, click

Devices

>

Identity Servers

>

Shared

Settings

>

Attribute Sets

> click

New

.

2

Provide the attribute set name as adfs-attributes.

3

Click

Next

with the default selections.

4

In the

Create Attribute Set

section, click

New

.

5

Select

ldapattribute mail

from the

Local Attribute

list.

6

Specify

emailaddress

in the

Remote attribute

field.

7

Select

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/

from the

Remote namespace

list.

8

Click

OK

.

9

Click

New

.

10

Select

All Roles

from the

Local Attribute

list.

11

Specify roles in the

Remote Attribute

field.

442

Configuring Authentication

12

Select

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/

from the

Remote namespace

list.

13

Click

OK

.

14

Update Identity Server.

Configuring the Service Provider in Access Manager

1

In the Access Manager Administration Console, select the ADFS service provider in the

SAML

2.0

tab.

2

Click

Authentication Response

.

3

Select

Binding to POST

.

4

Specify the name identifier format default value and select

unspecified

along with the defaults.

5

Click

Attributes

.

6

Select

adfs-attributes

from the

Attribute Set

list.

7

Select the required attributes to be sent with authentication. For example, the mail and cn attributes.

8

Click

OK

.

9

Update Identity Server.

Exporting the Identity Provider Metadata to a File

Access https://<<Identity server IP / dns name>>:8443/nidp/saml2/metadata in a browser and save the page as an XML file, such asnam_metadata.xml. AD FS 2.0 uses this file to automate the setup of the Access Manager Claims Provider instance.

Configuring AD FS 2.0

Using Metadata to Add Claims Provider

Editing Claim Rules for the Claims Provider Trust

Editing Claim Rules for the WIF Sample Application

Editing Claim Rules for the SharePoint 2010 Application

Disabling CRL Checking in the Linux Identity Server

Using Metadata to Add Claims Provider

You need to use the metadata import capabilities of AD FS 2.0 to create the Example.com claims provider. The metadata includes the public key that is used to validate security tokens signed by

Access Manager.

Using Metadata to Add a Relying Party

1

In AD FS 2.0, in the console tree, right-click the

Claims Provider Trusts

folder, then click

Add

Claims Provider Trust

to start the Add Claims Provider Trust Wizard.

2

Click

Start

.

3

On the Select Data Source page, select

Import data about the claims provider from a file

.

4

In the

Federation metadata file location

field, click

Browse

.

5

Navigate to the location where you saved nam_metadata.xml, click

Open

, then click

Next

.

6

On the Specify Display Name page, type NAM Example.

7

Click

Next

>

Next

>

Close

.

Configuring Authentication

443

Editing Claim Rules for the Claims Provider Trust

The following claim rule describes how the data from Access Manager is used in the security token that is sent to the WIF sample application or SharePoint 2010.

1

In AD FS 2.0, click

Relying Party Trusts

, right click

WIF Sample App

, and then click

Edit Claim

Rules

. or

In the AD FS 2.0 center pane, under

Claims Provider Trusts

, right-click

NAM Example

, then click

Edit Claim Rules

.

2

On the

Acceptance Transform Rules

tab, click

Add Rule

.

3

On the Select Rule Template page, select the

Pass Through or Filter an Incoming Claim

option.

4

Click

Next

.

5

On the Configure Claim Rule page, use the following values:

Name

Claim rule name

Incoming claim type

Incoming name ID format

Value

Name ID Rule

Name ID

Unspecified

6

Select the

Pass through all claim values

option and click

Finish

.

7

Click

Add Rule

.

8

On the Select Rule Template page, select the

Pass Through or Filter an Incoming Claim

option.

9

Click

Next

.

10

On the Configure Claim Rule page, under

Claim rule name

, use the following values:

Name

Claim rule name

Incoming claim type

Value

Name Rule

Name

11

Leave the

Pass through all claim values

option selected and click

Finish

.

12

To acknowledge the security warning, click

Yes

.

13

Click

OK

.

14

Click

Add Rule

.

15

On the Select Rule Template page, select the

Pass Through or Filter an Incoming Claim

option.

16

Click

Next

.

17

On the Configure Claim Rule page, in the

Claim rule name

field, use the following values:

Name

Claim rule name

Incoming claim type

Value

Email Rule

E-Mail Address

18

Leave the

Pass through all claim values

option selected and click

Finish

.

444

Configuring Authentication

19

To acknowledge the security warning, click

Yes

.

20

Click

OK

.

Editing Claim Rules for the WIF Sample Application

At this point, incoming claims have been received at AD FS 2.0, but rules that describe what to send to the WIF sample application have not yet been created. You need to edit the existing claim rules for the sample application to take into account the new Access Manager external claims provider.

1

In AD FS 2.0, click

Relying Party Trusts

.

2

Right-click

WIF Sample App

, then click

Edit Claim Rules

.

3

On the

Issuance Transform Rules

tab, click

Add Rule

.

4

On the Select Rule Template page, click

Pass Through or Filter an Incoming Claim

>

Next

.

5

On the Configure Claim Rule page, enter the following values:

Name

Claim rule name

Incoming claim type

Value

Pass Name Rule

Name

6

Leave the

Pass through all claim values

option selected, then click

Finish

.

7

On the

Issuance Transform Rules

tab, click

Add Rule

.

8

On the Select Rule Template page, click

Pass Through or Filter an Incoming Claim

.

9

Click

Next

.

10

On the Configure Claim Rule page, enter the following values:

Name

Claim rule name

Incoming claim type

Incoming Name ID format

Value

Pass Name ID Rule

Name ID

Unspecified

11

Leave the

Pass through all claim values

option selected, then click

Finish

.

12

Click

OK

.

NOTE:

If you changed the rules while federating AD FS 2.0 with the WIF sample application, ensure that you add the Permit All Users issuance rules back to the WIF sample application. See Step 6: –

Change Rules in the AD FS 2.0 Federation with a WIF Application Step-by-Step Guide .

Or, as an alternative, add a new Permit or Deny Users Based on an Incoming Claim rule allowing incoming Name ID = [email protected] to access the application.

Editing Claim Rules for the SharePoint 2010 Application

At this point, incoming claims have been received at AD FS 2.0, but the rules that describe what to be sent to the SharePoint 2010 application have not yet been created. You need to edit the existing claim rules for the SharePoint 2010 application, which is added as relying party to ADFS 2.0, to configure the new Access Manager external claims provider.

Configuring Authentication

445

Editing the Claim Rules for the SharePoint 2010 Application

1

In AD FS 2.0, click

Relying Party Trusts

.

2

Right-click

SP2010

, then click

Edit Claim Rules.

3

On the

Issuance Transform Rules

tab, click

Add Rule

.

4

On the Select Rule Template page, click

Pass Through or Filter an Incoming Claim

>

Next

.

5

On the Configure Claim Rule page, enter the following values:

Name

Claim rule name

Incoming claim type

Value

Pass eMail Rule

Email Address

6

Leave the

Pass through all claim values

option selected and click

Finish

.

Using Certificates and Certificate Revocation Lists

For security reasons, production federation deployments require the use of digitally signed security tokens, and optionally allows encryption of the security token contents. Self-signed private key certificates, which are generated from inside the AD FS 2.0 and Access Manager products, are used for signing security tokens.As an alternative, organizations can use a private key certificate that is issued by a certificate authority (CA) for signing and encryption. The primary benefit of using CAissued certificates is the ability to check for possible certificate revocation against the certificate revocation list (CRL) from the issuing CA. Also, to avoid the untrusted certificate messages in browsers, the trusted root certificate of the CA must also be imported into your browsers. Many wellknown CA's trusted roots are included with common browsers. Using one of these existing CAs to mint your certificates also prevents the untrusted certificate messages.

In AD FS 2.0 and in Access Manager, CRL checking is enabled by default for all partner connections, if the certificate being used by the partner includes a CRL Distribution Point (CDP) extension. This has implications in federation deployments between Access Manager and AD FS 2.0:

If a signing/encryption certificate provided by one side of a federation includes a CDP extension, that location must be accessible by the other side's federation server. Otherwise, CRL checking fails, resulting in a failed access attempt. The CDP extensions are added by default to certificates that are issued by Active Directory Certificate Services (AD CS) in Windows Server

2012.

If the signing/encryption certificate does not include a CDP extension, no CRL checking is performed by AD FS 2.0 or Access Manager.

Disabling CRL Checking in the Linux Identity Server

1

Modify /opt/novell/nam/idp/conf/tomcat.conf and add JAVA_OPTS="${JAVA_OPTS} -

Dcom.novell.nidp.serverOCSPCRL=false"

2

To apply the changes, restart Identity Server by running the /etc/init.d/novell-idp restart command.

Disabling CRL Checking in AD FS 2.0

1

Click

Start

>

Administrative Tools

>

Windows PowerShell Modules

.

2

Enter the following command at the PowerShell command prompt: set-ADFSClaimsProviderTrust -TargetName "NAM Example"

-SigningCertificateRevocationCheck None

446

Configuring Authentication

NOTE:

You can make many configuration changes to AD FS 2.0 by using the Windows PowerShell command line and scripting environment. For more information, see the AD FS 2.0 Windows

PowerShell Administration section of the AD FS 2.0 Operations Guide and the AD FS 2.0 Cmdlets

Reference (http://go.microsoft.com/fwlink/?LinkId=177389) .

Example Scenario: Access Manager as the Claims Provider and AD FS 2.0 as the Relying

Party

“Accessing the WIF Sample Application” on page 453

“Accessing the SharePoint 2010 Application” on page 453

Accessing the WIF Sample Application

In this scenario, John from Example.com accesses the Contoso WIF sample application.

NOTE:

Clear all the cookies in the Internet Explorer on the AD FS 2.0 computer

(fsweb.contoso.com). To clear the cookies, click

Tools

>

Internet Options

>

Delete

under

Browsing

History

, and then select cookies for deletion.

1

On the AD FS 2.0 computer, open a browser window, then navigate to https:// fsweb.contoso.com/ClaimsAwareWebAppWithManagedSTS/default.aspx.

The first page prompts you to select your organization from a list.

2

Select

NAM Example

, then click

Continue

to sign in.

When only one Identity Provider is available, AD FS 2.0 forwards the request to that Identity

Provider by default.

3

The NAM login page appears. Type the user name john, type the password test, then click

Login

.

Accessing the SharePoint 2010 Application

The user's email ID is used as the mapped attribute to access the SharePoint 2010 application.

Assume that a user is created in the NetIQ Identity Server. The email ID configured for this user is [email protected].

NOTE:

Clear all the cookies in the Internet Explorer on the AD FS 2.0 computer

(fsweb.contoso.com). To clear the cookies, click

Tools

>

Internet Options

>

Delete

under

Browsing

History

, then select cookies for deletion.

1

Ensure that an email ID has been configured for the user in the Access Manager user store.

For this example, use [email protected].

2

Access the SharePoint 2010 application.

The user is redirected to AD FS 2.0.

3

Select

NetIQ Identity Server

.

The user is redirected to the NAM IDP nidp page for authentication.

4

Provide namuser1 as the username and password.

After authentication, the user is redirected to the SharePoint application.

Configuring Authentication

447

Configuring AD FS 2.0 as the Claims or Identity Provider and Access Manager as the Relying Party or Service Provider

This section explains how to configure an application through AD FS 2.0 that gets federated access to an application by using Access Manager. The setup uses the SAML 2.0 POST profile.

“Configuring Access Manager” on page 454

“Configuring AD FS 2.0” on page 455

Configuring Access Manager

The AD FS metadata is used to add an Identity Provider to Access Manager.

“Getting the AD FS 2.0 Metadata” on page 454

“Using the Metadata to Add a New Identity Provider Connection” on page 454

“Adding the AD FS Server Trusted Certificate” on page 455

“Configuring the Identity Provider in Access Manager” on page 455

Getting the AD FS 2.0 Metadata

1

Access the AD FS server metadata by going to https://<<ADFS hostname or IP/

FederationMetadata/2007-06/FederationMetadata.xml

2

Save the AD FS metadata data.

3

Open the AD FS metadata file in Notepad, WordPad, or an XML editor).

4

Remove the <RoleDescriptor> tags from the metadata.

For example, remove the following tags:

"<RoleDescriptor xsi:type="fed:ApplicationServiceType"

protocolSupportEnumeration=http://..................... ……> ……….</

RoleDescriptor>

"<RoleDescriptor xsi:type="fed:SecurityTokenServiceType"

protocolSupportEnumeration=http://..... ………> </RoleDescriptor>

5

Save the changes.

Using the Metadata to Add a New Identity Provider Connection

1

In the Access Manager Administration Console, select

Devices

>

Identity Server

.

2

Click

Edit

.

3

Select

SAML 2.0

.

4

Click

New

>

Identity Provider

.

5

Specify the name as

ADFS

in the

Name

field.

6

Select

Metadata Text

from the

Source

list.

7

Paste the copied ADFS metadata that you saved in

Step 5 on page 454 into the

Text

field.

8

Click

Next

.

9

Specify an alphanumeric value that identifies the card in the

ID

field.

10

Specify the image to be displayed on the card in the

Image

field.

11

Update Identity Server.

448

Configuring Authentication

Adding the AD FS Server Trusted Certificate

1

Retrieve the AD FS server's CA trusted root certificate.

2

In the Access Manager Administration Console, select

Security

>

Certificates

.

3

Select

Trusted Roots

.

4

Click

Import

.

5

Specify the certificate name, and browse for the AD FS certificate authority.

6

Click

OK

.

7

Click

uploaded AD FS CA

.

8

Click

Add to Trusted Store and select config store

.

9

Update Identity Server.

Configuring the Identity Provider in Access Manager

1

Select the

AD FS Identity Provider

in the

SAML 2.0

tab.

2

Click

Authentication Card

>

Authentication Request

.

3

Select

Response Protocol Binding to POST

.

4

Select

NAME Identifier Format as Transient

.

5

Click

OK

.

6

Update Identity Server.

Configuring AD FS 2.0

“Using the Metadata to Add a Relying Party” on page 455

“Editing Claim Rules for a Relying Party Trust” on page 456

“Disabling the Certificate Revocation List” on page 456

“AD FS 2.0 Encryption Strength” on page 457

Using the Metadata to Add a Relying Party

The metadata import capability of AD FS 2.0 is used to create a relying party. The metadata includes the public key that is used to validate security tokens signed by Access Manager.

1

In AD FS 2.0, right-click the

Relying Party Trusts

folder, then click

Add Relying Party Trust

to start the Add Relying Party Trust Wizard.

2

Click

Start

.

3

On the Select Data Source page, select

Import data about the claims provider from a file

.

4

In the

Federation metadata file location

section, click

Browse

.

5

Navigate to the location where you saved nam_metadata.xml earlier, select the file, then click

Open

>

Next

.

6

On the Specify Display Name page, specify NAM Example.

7

Click

Next

>

Next

>

Close

.

Editing Claim Rules for a Relying Party Trust

The data from AD FS is used in the security token that is sent to Access Manager.

1

The Edit Claim Rules dialog box must already be open. If not, in the AD FS 2.0 center pane, under

Relying Party Trusts

, right-click

NAM Example

, then click

Edit Claim Rules

.

Configuring Authentication

449

2

On the

Issuance Transform Rules

tab, click

Add Rule

.

3

On the Select Rule Template page, leave the

Send LDAP Attributes as Claims

option selected, then click

Next

.

4

On the Configure Claim Rule page, specify Get attributes in the

Claim rule name

field.

5

Select

Active Directory

from the

Attribute Store

list.

6

In the

Mapping of LDAP attributes

section, create the following mappings:

LDAP Attribute

User-Principal-Name

E-Mail-Address

Outgoing Claim Type

UPN

E-Mail Address

7

Click

OK

.

8

Click

Apply

> OK.

9

On the

Issurance Transform Rules

tab, click

Add Rules

.

10

On the Select Rule Template page, select

Transform an Incoming Claim

, then click

Next

.

11

On the Configure Claim Rule page, use the following values:

Name

Claim rule name

Incoming Claim Type

Outgoing Claim Type

Outgoing name ID format

Value

Mapping To Transient Name Identifier

UPN

Name ID

Transient Identifier

12

Select

Pass Through All Claims

, then click

OK

.

13

Click

Apply

>

OK

.

Disabling the Certificate Revocation List

For more information about signing and encryption certificates, see “Using Certificates and Certificate

Revocation Lists” on page 452 .

Disabling the CRL Checking Option in the Linux Identity Provider

Disabling the CRL Checking Option in AD FS 2.0

1

Click

Start

>

Administrative Tools

>

Windows PowerShell Modules

.

2

Enter the following command at the PowerShell command prompt: set-ADFSRelyingPartyTrust -TargetName "NAM Example"

-SigningCertificateRevocationCheck None

450

Configuring Authentication

AD FS 2.0 Encryption Strength

In AD FS 2.0, encryption of the outbound assertions is enabled by default. Assertion encryption occurs for any relying party or service provider for which AD FS 2.0 possesses an encryption certificate. AD FS 2.0 uses 256-bit Advanced Encryption Standard (AES) keys or AES-256 for encryption. In contrast, Failing to reconcile these conflicting defaults can result in the failed SSO attempts. To resolve this issue, disable the encryption in AD FS 2.0.

1

In AD FS 2.0, click

Start

>

Administrative Tools

>

Windows PowerShell Modules

.

2

Enter the following command in at the PowerShell command prompt: set-ADFSRelyingPartyTrust -TargetName "NAM Example"

-EncryptClaims $False

AD FS 2.0 Basics

“Configuring the Token-Decrypting Certificate” on page 457

“Adding CA Certificates to AD FS 2.0” on page 457

Configuring the Token-Decrypting Certificate

1

Open the AD FS 2.0 Management tool, then click

Start

>

Administrative Tools

>

AD FS 2.0

Management

.

2

In the left pane, expand the

Service

folder and click

Certificates

.

3

In the

Certificates

section, select

Add Token-Decrypting Certificate

.

4

(Conditional) If you see an error prompting you to run certain commands during the tokendecrypting process, run the following PowerShell commands:

Add-PSSnapin Microsoft.Adfs.PowerShell

Set-ADFSProperties -AutoCertificateRollover $false

These commands allow you to select other certificates. The certificate must be installed on the server. The certificates are configured on the IIS Manager.

5

Click

Start

>

Administrative Tools

>

Internet Information Services (IIS) Manager

.

6

Click

ServerName

.

7

Click

Server Certificates

in the IIS section.

Adding CA Certificates to AD FS 2.0

1

In Windows,

Start

>

Run

>

mmc

.

2

Attach snapshot certificates as service.

3

Select

AD FS

.

4

Import the CA certificate to trusted authorities.

Configuring Authentication

451

Debugging AD FS 2.0

1

In the

Event Viewer

, click

Applications

>

AD FS

. You can access the troubleshooting help at

Troubleshooting certificate problems with AD FS 2.0 (http://technet.microsoft.com/en-us/library/ adfs2-troubleshooting-certificate-problems%28WS.10%29.aspx) .

Power Shell Commands Help:

Using Windows PowerShell for AD FS2.0 (http://technet.microsoft.com/en-us/library/adfs2-helpusing-windows-powershell%28WS.10%29.aspx)

AD FS 2.0 for Windows PowerShell Examples (http://technet.microsoft.com/en-us/library/adfs2powershell-examples%28WS.10%29.aspx)

Configuring SAML 1.1

This section explains how to use the SAML 1.1 protocol to set up the trust with internal and external identity providers, service providers, and Embedded Service Providers (ESPs). Topics include:

“Configuring a SAML 1.1 Profile” on page 458

“Creating a SAML 1.1 Service Provider” on page 459

“Creating a SAML 1.1 Identity Provider” on page 459

“Configuring Communication Security for SAML 1.1” on page 459

“Editing a SAML 1.1 Identity Provider’s Metadata” on page 459

“Editing a SAML 1.1 Service Provider’s Metadata” on page 459

“Configuring the SAML 1.1 Authentication Response” on page 459

“Defining Options for SAML 1.1 Service Provider” on page 460

“Modifying the Authentication Card for SAML 1.1” on page 460

Configuring a SAML 1.1 Profile

You can configure the methods of communication that are available at the server for requests and responses sent between providers. These settings affect the metadata for the server and must be determined prior to publishing to other sites.

Profiles control what methods of communication are available at the server for the SAML 1.1 protocol.

These settings affect the metadata for the server and must be determined prior to publishing to other sites. If you have set up trusted providers, and then modify these profiles, the trusted providers need to reimport the metadata from this Identity Server.

1

In the Administration Console, click

Devices > Identity Servers > Edit > SAML 1.1 > Profiles

.

2

Configure the following fields:

Login:

Specifies the communication channel when the user logs in. Select one or more of these methods for the identity provider and the identity consumer:

The Artifact binding provides an increased level of security by using the back channel for communication between the two servers during authentication.

452

Configuring Authentication

The Post method uses HTTP redirection to accomplish communication between servers.

The Post method is enabled by default and you are not able to modify the default settings.The Post profile creates a metadata that includes only a Post binding on the

Service Provider. If you have the default setup, then always both Artifact and Post options are enabled. If both the options are enabled, then by default Artifact binding is used. If

Artifcact binding is disabled or removed, only Post method is used.

Source ID:

Displays the hexadecimal ID generated by the Identity Server for the SAML 1.1 service provider. This is a required value when establishing trust with a service provider.

3

Click

OK

, then update the Identity Server.

4

(Conditional) If you have set up trusted providers and have modified the profile, these providers need to reimport the metadata from this Identity Server.

Creating a SAML 1.1 Service Provider

See

“Creating a Trusted Service Provider” on page 152 .

Creating a SAML 1.1 Identity Provider

See

“Creating a Trusted Identity Provider” on page 150

.

Configuring Communication Security for SAML 1.1

Liberty and SAML 1.1 have the same security options for the SOAP back channel for both identity and service providers. See

“Configuring Communication Security for Liberty” on page 463

Editing a SAML 1.1 Identity Provider’s Metadata

See

“Editing a SAML 1.1 Identity Provider’s Metadata” on page 160

.

Editing a SAML 1.1 Service Provider’s Metadata

See

“Editing a SAML 1.1 Service Provider’s Metadata” on page 161

.

Configuring the SAML 1.1 Authentication Response

You can specify the name identifier and its format when the Identity Server sends an authentication response. You can also restrict the use of the assertion.

When an identity provider sends an assertion, the assertion can be restricted to an intended audience. The intended audience is defined to be any abstract URI in SAML 1.1. The URL reference can also identify a document that describes the terms and conditions of audience membership.

1

In the Administration Console, click

Devices > Identity Servers > Edit > SAML 1.1 > [Service

Provider]

>

Authentication Response

.

2

To specify a name identifier format, select one of the following:

E-mail:

Specifies that an e-mail attribute can be used as the identifier.

X509:

Specifies that an X.509 certificate can be used as the identifier.

Configuring Authentication

453

Unspecified:

Specifies that an unspecified format can be used and any value can be used.

The service provider and the identity provider need to agree on what value is placed in this identifier.

3

To specify the format of the name identifier, select an attribute.

The available attributes depend upon the attributes that you have selected to send with authentication (see the Attributes page for the service provider).

4

To configure an audience, click

New

.

5

Specify the

SAML Audience URL

value.

The Provider ID, which can be used for the audience, is displayed on the Edit page for the metadata.

6

Click

OK

twice, then update the Identity Server.

Defining Options for SAML 1.1 Service Provider

For more information about Options, see “Defining Options for a SAML 2.0 Service Provider” on page 441

1

In Administration Console, click

Devices > Identity Servers > Servers > Edit > SAML 1.1 >

Service Provider

>

Options

.

2

Select the required step up authentication contracts from the

Available Contracts

list and move them to the

Selected Contracts

list. These selected contracts will be used to provide the step up authentication for the service provider.

3

Click

OK

.

Modifying the Authentication Card for SAML 1.1

When you create an identity provider, you must also configure an authentication card. After it is created, you can modify it.

1

In the Administration Console, click

Devices > Identity Servers > Edit > SAML 1.1 > [Identity

Provider] > Authentication Card.

2

Modify the values in one or more of the following fields:

ID:

If you have need to reference this card outside of the user interface, specify an alphanumeric value here. If you do not assign a value, the Identity Server creates one for its internal use. The internal value is not persistent. Whenever the Identity Server is rebooted, it can change. A specified value is persistent.

Text:

Specify the text that is displayed on the card to the user. This value, in combination with the image, must identify to the users, which provider they are logging into.

Login URL:

Specify an Intersite Transfer Service URL.The URL has the following format, where idp.sitea.novell.com is the DNS name of the identity provider, idp.siteb.novell.com is the name of the service provider, and idp.siteb.novell.com:8443/nidp/app specifies the URL that you want to users to access after a successful login.

NOTE:

The PID in the login URL must exactly match the entity ID specified in the metadata. https://idp.sitea.novell.com:8443/nidp/saml/idpsend?PID=https:// idp.siteb.novell.com:8443/nidp/saml/metadata&TARGET=https:// idp.siteb.novell.com:8443/nidp/app

454

Configuring Authentication