This documentation supports the 9.0 version of BMC Atrium Single Sign-On, which is in "End of Version Support." However, the documentation is available for your convenience. You will not be able to leave comments.

Click here to view the documentation for a supported version of Remedy Single Sign-On.

Configuring BMC Atrium Single Sign-On as an SP

In a Circle of Trust (COT), BMC Atrium Single Sign-On is normally configured as a Service Provider (SP) for BMC products. The Circle of Trust is then completed with an Identity Provider (IdP) to provide authentication for the federated single sign-on.

The following topics are provided:

Verifying that certificates were imported into the truststore

Before configuring BMC Atrium Single Sign-On with a Service Provider, verify that all the certificates used for network communication (Transport Layer Security) between the servers that are participating in the Circle of Trust have been imported into the truststore of BMC Atrium Single Sign-On:

  • If you are using signed certificates, verify that only the root Certificate Authority (CA) certificate is imported.
  • If you are using self-signed certificates, verify that the public certificates are imported into the truststore.

For more information about importing certificates, see Managing certificates in BMC Atrium Single Sign-On and Importing a certificate into the truststore.

Note

If you are modifying the local SP configuration using the Local SP Editor, you must also modify your configuration on the IdP server. You must make the changes from the local SP to the remote IdP. For example, if you have configured BMC Atrium Single Sign-On as an SP and the Active Directory Federated Services (AD FS) server as an IdP, and you modify your AD FS server settings, you must also reconfigure the settings on your Remote IdP Editor either manually or by reimporting the metadata. Also, if you have changed your settings on the Local SP Editor, you must reconfigure the AD FS sever either manually or by reimporting the SP metadata.

Creating a local SP

If you are using a second BMC Atrium Single Sign-On server as an IdP, export the certificate from that server from the <installationDirectory>/tomcat/conf/keystore.p12 file and import it into cacerts.p12 on the BMC Atrium Single Sign-On server that is providing the SP role.

To create a local SP

  1. On the BMC Atrium SSO Admin Console, select the realm that you want to edit.
  2. On the Federation tab, click Add.
  3. Select Local Service Provider (SP).
  4. Provide the local SP information.
  5. Click Save.

Local SP parameters

The Local Service Provider (SP) Editor contains the following options:

Unknown macro: {multi-excerpt-include}

The fields on the local SP editor are as follows:

Services tab

Field

Parameter

Description

Name

 

Enter the name for the SP.

View SAMLv2 Metadata Click this option to view metadata XML for the configured SP.  When you click View SAMLv2 Metadata, a new page opens, displaying the metadata.

MetaAlias

 

The internally generated identifier for the entity. This value is used in the SAMLv2 login URL specified in the agents configuration.

Binding

 

Select the binding option. This option determines the way in which SAML messages will be sent and received between the IdP and the SP. HTTP-Redirect and Post are used when a direction connection between the IdP and SP is not possible. The two bindings differ in the method used to exchange the SAMLv2 messages: HTTP Redirect or XHTML Form with Post.

SOAP Basic Authentication

Name

Password

SOAP Basic authentication can be enabled to protect the SOAP SP endpoints. Any provider accessing these endpoints must provide these name and password values.

 Notify IdP of Session TimeoutSelect the check box if you want to send the session timeout message to the IdP server.

Signing/Encryption tab

Field

Parameter

Description

Sign Messages

Signing Certificate Alias

The alias specifies the certificate that will be used to sign the specified SAML messages. Signing is used to verify that whether the messages have not been altered in transit and that it originated with the IdP.

Select the certificate that you want to use for signing the SAML messages. Click View to see the certificate details.

 

Authentication Request, Logout Request, Logout Response, Assertions, Manager Name ID Request, Manager Name ID Response, Artifact Response, and Post Response

Select the relevant signing parameter from the options. These parameters are the SAMLv2 messages that are to be signed by the IdP or are expected to have been signed by the SP.

Encrypt Elements

Encryption Certificate Alias

Select the Encryption Certificate Alias from the list. The alias specifies the private key that will be used to encrypt the secret key used to encrypt the SAMLv2 messages.

 

Encryption Algorithm

The encryption algorithm used to encrypt SAMLv2 messages. Select an option, None, 3DES, AES-128, or AES-256, from the drop-down list.

 

Assertion, Attribute, Name ID

Select the check boxes if you want to encrypt the Assertion, Attribute, or Name ID parameters instead of using plain text.

Note: When you are using BMC Atrium Single Sign-On as an IdP for SAMLv2 authentication using encryption, you must select the relevant check box: Assertion, Attribute or Name ID. You must use the same encryption for the Remote SP as well.

Authentication Request

Field

Parameter

Description

Authentication Context

Default Authentication Context

This attribute maps the SAMLv2-defined authentication context classes to the authentication level set for the user session for the service provider.

 Comparison Type

Select the default context that you are planning to use for authentication and what level of comparison do you want for authentication. The options are: exact, minimum, maximum, better, none.

 Name ID Formats

Defines the name identifier formats supported by the service provider. Name identifiers are a way for providers to communicate with each other regarding a user.

The Name ID format list is an ordered list, the first Name ID has the highest priority in determining the Name ID format to use. If the user does not specify a Name ID to use when initiating single sign-on, the first one in this list is chosen and supported by the remote Identity Provider.

A persistent identifier is saved to a particular user's data store entry as the value of two attributes. A transient identifier is temporary and no data will be written to the user's persistent data store.

Note:

For linking user accounts from SP and IdP (Remote Identity Provider) together, after logging in, the persistent nameID format must be on the top of the list.

Logging tab

Field

Parameter

Description

Logging

Logging Level

Enable logging and click View to see the logging information in web page. The logging panel will allows you to turn on logging specifically for the SP and IdP. This isolated logging provides you targeted logs going through the debug.out file. You can access these log files by clicking View in this field.
The logging level options are:

  • All — All the details related to SP or IdP will be saved in the log file.
  • Info — Messages related to assertion will be saved as warnings in the log file.
  • Off — No logs will be generated.

The log file is created in the <SSO_HOME>/tomcat/logs directory and has the following name format: realm_<REALM_NAME>_<ENTITY_ID>.<FILE_NUMBER>.log, where

    • REALM_NAME is the name of the realm in which the federation entity is created
    • ENTITY_ID is the ID of the federation entity for which the logging is switched on
    • FILE_NUMBER  is the number of the parts of the log file. A new file is generated after the log file size is more than the predefined size for a file.

Assertion Processing tab

Field

Parameter

Description

Artifact Encoding

 

The encoding technique used for Assertion Artifacts. The encoding method is determined by the IdP and is usually related to binding method. From the drop down menu, select URI or FORM.

Assertion Time

Not-Before Skew (seconds)

In order to compensate for clock drift between remote machines, this value specifies the amount of time that a message will be considered valid when it is received before the issue time in the message.

Attribute Mapping

SAML Attribute

Atrium SSO Attribute

Attribute Mapping is used to take user attributes (such as email, phone number, etc.) from the external user store and map them to the attributes used within the BMC Atrium Single Sign-On system. A mapping is defined by entering the name of the SAML Attribute and selecting the Atrium SSO Attribute from the drop down that the external attribute is going to map to, and click Add to put the new mapping into the table.

Auto Federation

 

Allows BMC Atrium Single Sign-On to use an attribute of the Assertion from the IdP to automatically create an identity within the BMC Atrium Single Sign-On system. The identity is created by passing the initial double-login normally performed when federating a user account with SAMLv2.

Use Name ID as User ID When the Use Name as UserID is selected, the system automatically logs the user into the BMC Atrium Single Sign-on server using the NameID value from the SAMLv2 Assertion. This automatic login is a form of auto-federation.

Creating a remote IdP

  1. On the BMC Atrium SSO Admin Console, select the realm that you want to edit.
  2. On the Federation panel, click Add.
  3. Select Remote Identity Provider (IdP).
  4. Import a signed certificate into the cot.jks keystore used for SAMLv2 authentication.

    The cot.jks file is located at <installationDirectory>/tomcat.

  5. Create a name for the remote IdP and upload the IdP metadata using the Create Identity Provider (IdP) window. For more information about the parameters, see Create Identity Provider.
  6. Click Save.
  7. On the Federation panel, select the remote IdP.
  8. Click Edit.
  9. Provide the remote IdP parameters.
  10. Click Save.

Remote IdP editor parameters

Note

Your browser must be able to access the IdP server for authentication.

The Remote Identity Provider (IdP) editor contains the following options:

Unknown macro: {multi-excerpt-include}

The fields on the Remote IdP editor are as follows

Field

Parameter

Description

Name

 

Name for the IdP or accept the provided IdP name. The Name field is pre-populated with a value that reflects the expected IdP name.

View SAMLv2 Metadata Click this option to view metadata XML for the configured IdP.  When you click View SAMLv2 Metadata, a new page opens, displaying the metadata.

Binding

 

This option determines the way in which SAML messages will be sent and received between the IdP and the SP. HTTP-Redirect and Post are used when a direct connection between the IdP and SP is not possible. The two bindings differ in the method used to exchange the SAMLv2 messages: HTTP Redirect or XHTML Form with Post.

Sign Messages

Signing Certificate Alias

The alias specifies the certificate that will be used to sign the specified SAML messages. Signing is used to verify the messages have not been altered in transit and that it originated with the IdP.

Click View to see the selected signing certificate details.

 

Authentication Request, Logout Request, Logout Response, Manager Name ID Request, Manager Name ID Response, and Artifact Resolve

These parameters are the SAMLv2 messages that are to be signed by the IdP or are expected to have been signed by the SP.

Encrypt Elements

Encryption Certificate Alias

The alias specifies the private key that will be used to encrypt the secret key used to encrypt the SAMLv2 messages.

Click View to see the selected encryption certificate details.

 

Encryption Algorithm

The encryption algorithm used to encrypt SAMLv2 messages. Select an option, None, 3DES, AES-128, or AES-256, from the drop-down menu.

 

Name ID

Specifies whether to encrypt the Name ID or leave it in plain text.

Modifying the JEE agents

As part of configuring BMC Atrium Single Sign-On to host an SP, you must modify the configuration of the JEE agents to work with SAMLv2 federation.

Note

Each time a BMC product is integrated with the BMC Atrium Single Sign-On SP, you must modify the configuration so the integrating product can work with federated BMC Atrium Single Sign-On server.

  1. On the BMC Atrium SSO Admin Console, click Agent Details.
    For more information about agent properties, see Agent manager in multi tenant environment.
  2. Select the agents associated with a BMC product integrated with this BMC Atrium Single Sign-On server; for example, arsystem@sample.bmc.com:8443.
  3. Perform one of the following actions:

    • If you have a single realm, click Edit.

    • If you have multiple realms, open the Realms tab.

    1. Perform the following actions:
  4. Perform the following actions:
    • Delete the URLs in the login URI field.
    • Delete the URLs in the logout URI field.
  5. Click Save.

    Note

    For more information about mapping realm URLs to the agent, see Mapping realm URLs to an agent for multi-tenancy.

Federated login URL syntax

https://<host>:<port>/atriumsso/spssoinit?metaAlias=<metaalias>&idpEntityID=<entityId>

In this example, the following descriptions apply:

  • host is the FQDN of the BMC Atrium Single Sign-On server hosting the SP.
  • port is the port used for secure communication of the Atrium Single Sign-On server hosting the SP.
  • entityId is the name of the IdP to be used by this SP.
  • metaalias is its own token with the value identified by the SP.

Federated logout URL syntax

https://<host>:<port>/atriumsso/saml2/jsp/spSingleLogoutInit.jsp?idpEntityID=<entityId>&RelayState=<webappURL>

In this example, the following descriptions apply:

  • host is the FQDN of the BMC Atrium Single Sign-On server hosting the SP
  • port is the port used for secure communication of the BMC Atrium Single Sign-On server hosting the SP.
  • entityId is the name of the IdP to be used by this SP.
  • webappURL is the URL for the webapp for this agent.

(Optional) Federating your user accounts in bulk

For information about using bulk federation, see Federating user accounts in bulk.

Where to go from here

See Administering for information about managing users, user groups, and authentication modules.

Was this page helpful? Yes No Submitting... Thank you

Comments