This AppNote explains configuration and troubleshooting options for implementing SAML 1.1 in your environment. It will not explain how SAML works nor how Novell Access Manager works. We’ll use an example to illustrate the information discussed in this document. In this example we’ll explain how you can set up trust between two Novell Access Management Identity Servers, using a Browser/POST profile.
Imagine that there is an organization called Government that has a directory of all its civilians. Currently civilians can authenticate to the Government portal with an Electronic Identity Card (eID), with a Federal Token, or with a combination of user name and password. The Government is going to set up an Authentication Service with a SAML1.1 Identity Provider.
On the other hand, there is a company (called Company) that needs to have a method to securely identify customers who want to have access to their services. They decided to use the Authentication Service of the Government to make sure that users are identified correctly.
If we talk about the Identity Provider, we actually mean here an Identity Server that is acting as an Identity Provider; if we talk about the Service Provider, we actually mean here an Identity Server that is acting as a Service Provider. Please be aware that an Identity Server can be both an Identity Provider and a Service Provider.
Configuring the Identity Provider
The Identity Provider needs to be aware about the existence of SAML1.1 Service Providers, therefore we need to create a trusted Service Provider. This setup will be done in the identity configuration SAML1.1 tab.
Figure 1 – Identity Provider, SAML 1.1 tab
There are multiple ways to create the trusted provider: you can import the metadata, or you can enter the configuration manually. The location to the metadata is http(s)://serverdns:port/nidp/saml/metadata. This metadata is an XML document that describes the remote Identity Server.
Figure 2 – Creating the Trusted Service Provider
When configuring a trusted Service Provider using the metadata, the information that is needed by the Identity Server is extracted from the metadata. If you create the Service Provider manually, you’ll need to provide the information yourself.
- EntityDescriptor entityID: When requests arrive at the Identity Provider, they are identified with this entityID.
- SPSSODescriptor: This describes the configuration of the Service Provider. From this XML, we can see that the Service Provider will only accept the Browser/POST profile and that the Post Consumer URL is https://serverdns:port/nidp/saml/spassertion_consumer. The X509Certificate element contains the public certificate that is used to sign SAML data.
Figure 3 – Specifying metadata
After the trusted Service Provider is created (with metadata or manually), you can configure or change the settings. You may, for example, change the Provider ID here, or when the certificates expiration date is approaching, you can import a new certificate. If you are going to use the Browser/Artifact profile, you’ll need to specify the Artifact consumer URL, which is the same as the Post Consumer URL for a Novell Access Management Identity Server.
Figure 4 – Configuring Service Provider settings
The next step is to add the Service Provider CA certificate to the NIDP Trust Store.
1. Click Auto-Import from Server. This needs to be done because the certificate that the Service Provider uses to sign SAML data needs to be trusted.
Figure 5 – Adding the Service Provider CA certificate
You can add attributes in the assertion that the Identity Provider sends to the Service Provider. That will enable you to use these attributes in the policy engine. The first thing to do is to create an attribute set.
2. Locate the Attribute Sets in the Setup tab from the Identity Servers list.
Local Attributes are attributes available to the Identity Provider and Remote Attributes are the names that will appear in the assertions.
Now you need to specify which attributes from this Attribute Set need to be send to the Service Provider.
3. Go to the configuration from the truster Service Provider and click the Access tab.
Figure 8 – Assertion data
As an extra step,
4. Choose what profile the Identity Provider will use to reach the Service Provider.
We already configured the trusted Service Provider with only the Browser/POST profile, so the Identity Provider will not try to use Browser/Artifact profile. If the metadata specifies both profiles, you can use the Profiles configuration tab and configure the preferred profiles there beneath Identity Profiles.
Configuring the Service Provider
When a Service Provider receives an assertion from the Identity Provider, you need to make sure it trusts the Identity Server and that it can decrypt and check the Signature in the assertion. To do this,
5. Configure the Identity Provider as trusted in the Service Providers Identity Server configuration.
Figure 10 – Trusting the Identity Provider
There are multiple ways to create the trusted Identity Provider: you can import the metadata, or you can enter the configuration manually. The location to the metadata is http(s)://serverdns:port/nidp/saml/metadata. This metadata is an XML document that describes the remote Identity Server.
Figure 11 – Specifying the name and metadata
When configuring a trusted Identity Provider using the metadata, the information that is needed by the Identity Server is extracted from the metadata. If you create the Identity Provider manually, you’ll need to provide the information yourself.
- EntityDescriptor entityID: If an assertion is retrieved, the Service Provider will check the Issuer value from the Assertion element. If this is the same as the entityID, he will use this configuration to analyze the assertion. This field identifies the Identity Provider.
- AttributeAuthorityDescriptor: The description of the attribute query processor on the Identity Provider. Via the attribute query, we can request a set of attributes associated with a specific subject.
- IDPSSODescriptor: This will describe the configuration of the Identity Provider. The KeyDescriptor elements contains the signing certificate of the SAML 1.1 identity provider. You’ll need this public certificate to validate the signatures in the assertions.
- SPSSODescriptor: This will describe the configuration of the Service Provider on the remote Identity Server.
Figure 12 – Metadata view
After you create the trusted Identity Provider (with metadata or manually), you can configure or change the settings. You can, for example, change the Provider ID here, or when the certificates expiration date approaches, you can import a new certificate. If you’re using the Browser/Artifact profile, you’ll need to specify the Artifact resolution URL. This is the same as the SAML attribute query URL for a Novell Access Management Identity Server. The Attribute Authority certificate is the signing public key certificate of the partner SAML 1.1 attribute authority. The Identity Provider certificate is the signing certificate of the partner SAML 1.1 identity provider, which is the certificate the partner uses to sign authentication assertions.
Figure 13 – Providing the Artifact resolution URL
Because you’re using a public server certificate from the SAML1.1 partner to check the signatures, you also need to trust this certificate.
6. Import the root CA Certificate that issued the partners server certificate. This root CA certificate (and if needed intermediate certificates) needs to be imported into the NIDP Trust Store.
Figure 14 – Trusted root certificates
7. Configure what will happen after the Assertion is validated correctly.
You can either try to map the user to an existing user in the local configured user store, or if the user is not existing in the local tree, you can decide to do nothing. If the operation is successful, you can assign a contract to this authentication.
Figure 15 – Access authentication
The attributes in the assertion that the Identity Provider sends to the Service Provider need to be mapped to usable attributes. For this example, we’ll use the Personal Profile. The first thing to do is to create an attribute set.
8. Locate the Attribute Sets in the Setup tab from the Identity Servers list.
Local Attributes are attributes available to the Identity Provider and Remote Attributes are the names that are found in an assertion.
Figure 16 – Mapping attributes from assertion
9. If you want to use the Profile in the policy engine from the Access Gateway, enable this profile in the Liberty tab. (Remember that the Identity Server has a Liberty trust relation with the Access Gateways Service Provider).
Figure 17 – Enabling the profile – Liberty tab
Below is a sample Form Fill policy. We are using the Liberty User Profile Attributes that are populated using the SAML1.1 trust relationship.
Figure 18 – Sample Form Fill policy
You need to identify yourself to the Identity Server and ask the Identity Server for an Assertion or Artifact. You can then present this to the Service provider to prove that you are authenticated to the Identity Server. This can be done via the Transfer URL. For a Novell Access Management Identity Provider, this URL is https://serverdns:port/nidp/saml/idpsend.
Two parameters need to be added to this URL. The first one is PID, the same value you configured in the trusted Service Provider on the Identity Provider. The value corresponds to EntityDescriptor entityID. With this parameter you tell the Identity Provider which trusted Service Provider you want to access. The second value is the TARGET value. This is the place where you want to be after the authentication has been verified.
Figure 19 – Access Manager local login
After you have been successfully authenticated to the Identity Provider, the Identity Provider will redirect you to the Service Provider Consumer URL, which is https://serverdns:port/nidp/saml/spassertion_consumer. (This is configured in the trusted Service Provider on the Identity Provider.)
You need to send an Assertion or Artifact to the Service Provider. The Artifact will be used by the Service Provider to get the Assertion from the Identity Provider. If the Service Provider receives the Assertion, it will analyze the Assertion and will send the Browser to TARGET if the Assertion is valid.
Figure 20 – Simple form example