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.
Scenario
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Below is a sample Form Fill policy. We are using the Liberty User Profile Attributes that are populated using the SAML1.1 trust relationship.
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.
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.
Support
Documentation
Learning Services
Partner Programs