Share This:

In this post we are going to take a look at configuring & troubleshooting SAML authentication with Remedy Single Sign-On. We will take a look at the two most popular SAML implementation, Active Directory Federation Service (ADFS) and OKTA.

 

Versions used in this post

RSSO 9.1.04

ADFS V3

OKTA (latest sanbox dev version as of 04/2018)

Remedy AR server / Midtier 9.1.04

sso.bmc.com domain

 

In the post we'll take a high level look at what SAML is and how it works. We'll then continue to configure RSSO with OKTA and ADFS. Finally we'll take a look at how to troubleshoot authentication problems with SAML.

 

What Is SAML?

SAML (Security Assertion Mark up Language) is a is an Extensible Markup Language (XML) standard that allows a user to log on once for affiliated but separate web applications.

The purpose of SAML is to provide centralized management of userid and password to allow access to applications from different vendors.  SAML uses XML to create assertions for users. The assertions includes information for access to application, token for the user along with other information such as user’s location, role etc..

 

The two most popular implementations using the SAML protocol are OKTA and Microsoft's ADFS

 

The are three main components in SAML implementation

• User. The end user who requests a service the service request can include access to sales force, webex MS 360 etc.  (User Browser)

• Service provider (SP). This is the application which provides the user with the service they request, it also sends authentication requests to the IDP to authenticate the user (RSSO)

• Identity provider (IDP). The central database for users, does the Authentication of the user and send the assertion back to the service provider to allow access for the user. (ADFS, OKTA)

 

SAML Process Flow

The SP hosts and protects the services that the user accesses. Remedy SSO is configured as an SP for BMC products. The IdP authenticates users and provides details of the authentication information to the SP.

The following table provides the workflow for the SAMLv2 logon authentication that is SP initiated:

StageDescription
1User accesses the protected application from a mobile device or through a web browser.
2Web Agent redirects the user to Remedy Single Sign-On (Remedy SSO) console.
3Remedy SSO sends a request to IdP to authenticate user.
4IdP presents a login form to user for authentication.
5User enters valid credentials.
6.IdP performs user authentication.
7.IdP forms authentication response and sends it back to the Remedy SSO server.
8.Remedy SSO server processes authentication response, validates it, and extracts the assertion that carries user data.
9.Remedy SSO creates a session for the user.
10.The user is allowed to access the application.

 

 

Identity Provider:  Identity Provider (IDP) maintains, and manages identity, it provides authentication as a service. IDP usually uses a directory service at the backend as its user store. An IDP in terms of SAML can be any system that 1. Provides Identity & Authentication services 2. Uses the SAML v.2 Protocol

 

Service Provider: Service Provider (SP) Is a system entity that receives and accepts authentication assertions in conjunction with a single sign-on (SSO) profile of the Security Assertion Markup Language (SAML).

 

NameIDFormat: - The providers in a SAML environment (Identity Provider & Service Provider) needs a common way to identify the userID attribute when sending SAML assertions. The NameID format specifies the common format that providers will use. There are times when there are more that one NameID format in the assertion, depending on what format is being used will determine which one will get used by the providers, Commonly used NameID formats are

 

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified - This is the default NameID format. This is left to the IDP to decide how to interpret the assertion elements and it assumes the SP knows how to parse the format data respond from the IDP

 

urn:oasis:names:tc:SAML:2.0:nameid-format:transient - Indicates that the content of the element is an identifier is treated as a temporary value by the relying party.  A transient identifier is temporary and no data will be written to the user's persistent data store.

 

urn:oasis:names:tc:SAML:2.0:nameid - format:persistent - A persistent identifier is saved to a particular user's data store entry as the value of two attributes

 

 

Configuring OKTA With RSSO

In this section we are going to have a look at configuring SAML Authentication with RSSO using OKTA.  We will be going through the whole process from creating the RSSO OKTA app to configuring RSSO to use it.

 

TIP: If you are configuring SAML OKTA on a dev system, it might be useful to create yourself a developer OKTA account, then you can test the configuration fully without having to ask the OKTA administrators to keep changing parameters as they may not be readily available. See attached doc oktadevsignup.docx below for instructions on how to sign-up for an OKTA accoung. Going through this process will also have the added benefit of showing how the OKTA saml authentication process works with hands-on experience plus you can follow along with the rest of this post.

 

Required information for OKTA SAML Configuration:

RSSO server service url: https://rssolb.bmc.com:8443/rsso/reciever  (The example we will use in this post)

Service Provider Identity: RSSO  (The example we will use in this post)

 

Summary of steps

1. Login to OKTA

2. Create the RSSO OKTA app

3. Provide the RSSO OKTA app with the relevant rsso server information

4. Import the OKTA Meta data in RSSO

5. Test the application login

 

In this example RSSO will be the service provider (SP) and OKTA the Identity Provider (IDP). The following procedure is an OKTA administrator function, and should be sent to the OKTA administrators to action. If you have created an OKTA dev account you can also follow this procedure to create the RSSO application in OKTA. Since most companies have an LDAP system with their users information in we will also be integrating OKTA to an internal LDAP system which is active directory.

 

Vid1. Goes through the procedure of login into OKTA and start creating a new application.

 

Once we've logged in and created the RSSO app we will come to the OKTA SAML integration page. Here we will need to provide the information of our RSSO system. In the "Single sign on URL" field enter in the url to the RSSO server /reciever  i.e https://rssolb.bmc.com:8443/rsso/receiver . Leave the "Use this for Recipient ULR and Destination ULR" check box ticked.

In the "Audience URI (SP Entity ID)" field enter the RSSO SP Identity, this can be found in the RSSO admin console under General-->Advanced (fig1)

 

Fig1. Shows the configured SP name of the RSSO configuration.

If you don't have an SP Identity name at this point then enter one, the SP name can be anything but the recommendation is to set a name which will identify RSSO quickly in this example the SP Entity ID is "RSSO"

 

We will leave "Name ID format" to "Unspecified" & "Application username" to "Okta username", we can change these later if required to meet organisational requirements. Click the "Show Advanced Settings" link. Under the advance settings we won't change anything at the moment, we can change these fields at a later point depending on organisational policies, these advanced options will form part of the OKTA's meta data that we'll need to import into RSSO later on in the configuration process .  We can preview the SAML Assetion, this will shows the IDP's meta data, if you want to see this click the "Preview the SAML Assertion Button". To see a description of each field on the OKTA SAML integration page click the question mark button next to the field.

 

Fig2. OKTA SAML integration page filled out.

 

Click Next on the OKTA SAML integration page. On the next screen click "I'm a software vendor. I'd like to integrate my app with okta" since we are at a development stage, if you are an OKTA customer then select the option and fill out the details requested. Then click "Finish" DO NOT click the "Submit your app for review" nothing bad will happen its just that we won't be able to use the app until OKTA has verified it.

 

You will be redirected to the "Sign On" page (fig3)

 

Fig3.

On this page click "Identity Provider metadata is available if this application supports dynamic configuration" button. This will show you and xml formated page with the OKTA meta data in, we will need this data for the RSSO configuration later on in the configuration process. You can either copy the url in the address bar or save the file locally on to the desktop (fig4 )

 

Fig4.

Users & Groups

There are two methods you can use in OKTA to use for user logins

 

1.OKTA's internal user store

2. LDAP/Active Directory integration

 

Internal User Store

 

Vid2. The following video with go through the process of creating a user in the OKTA internal user store. We can use this user to login to our application later on

 

LDAP/Active Directory Integration

 

Vid3. This video goes through the process of integrating LDAP/Active directory with OKTA so your organisation's users and groups will be available in OKTA. You will need to have access to the LDAP server. This is a function of the LDAP/AD administrators and should be actions by them.

 

 

Now that we have our user's in OKTA either created in the internal user store or integrated with LDAP/Active directory, our next step is to do the integration with RSSO.

 

Assigning Applications to users in OKTA

In OKTA we have to assign our newly created application either to an individual user or group, this process gives permission to a particular user or a group of users to use the application. Since this is an Single Sign-on application the users will not see the application directly, instead when they login to an application they will see the OKTA login page and once successfully logged in will see the application they have called

 

Vid4. Goes through the process of giving users or groups permission access to the RSSO application

 

OKTA integration with RSSO

For this example we are going to create a new realm in RSSO called "OKTASAML"

1. Login to the RSSO admin console go to General-->Advanced

2. Under "SAML Service Provider" ensure the following fields are filled out

  • SP Entity ID - This is the ID that the service provider (RSSO) will be known to OKTA, this should have been filled out already when configuring the OKTA portion (see above)
  • External URL - The RSSO service URL. Location to the RSSO server /rsso at the end, this url needs to be resolvable on the network
  • KeyStore/Password/Signing Alias - The location of the keystore file/the keystore password & the signing alias which will be the certificate used by RSSO to present to OKTA for verification (see  online documentation Setting SP signing certificate for SAML authentication

 

Fig5. Shows the basic (prerequisite) configuration for SAML in RSSO

3. On the RSSO admin console go to Realm-->New Realm (as mentioned we are going to create a new realm called "OKTASAML", but any realm can be used such as the "*" realm)

4. Give the new realm a name. For the application domain in this example we are going to enter "redmymtokta.bmc.com" this needs to be resolvable on the network, this will be the url we are going to access the Remedy Midtier with i.e. http://redmymtokta.bmc.com:8080/arsys, when this url is called it will tell RSSO to use the OKTASAML Realm and what ever authentication is configured (fig6).

 

Fig6.  Shows the configuration of the application domain, normally the application server name or the load balancer FQDN

5. Go to Authentication on the Authentication Type drop down select SAML

6. Click Import, here you have two options either enter the url to the OKTA IDP meta data or if you have download the meta data .xml file choose "Import from local file" option

In this case with are going to use the URL to the meta data (see above in the OKTA configuration portion on how to get the meta data) click Import

7. Once the import has been done, the OKTA meta data will be imported and the IDP fields will be filled out

8. Because we need to sign our OKTA request select the "Sign request" option

8.1 OKTA unless you have changed the configuration will send userID in the email format user@domain.com for AR server unless the user is in that format in the user or people form

you will get an error login in, you will have to check the format of the users in the CTM:People form or User form and use one of the RSSO "User ID Transformation" options  i.e

"Remove Domain" Or "Remove email domain" In this example since the user in AR is in the email format we won't need to select this option

9. Click ADD

10. Click edit on the realm scroll down and clock "View metadata" here you will see the SP meta data (fig7)

 

Fig7. Shows the SP (RSSO) meta data after configuration

Vid5. Shows the process of locating the OKTA metadata, importing the OKTA metadata into RSSO & view the RSSO SP metadata

 

We have now finished the basic configuration for integrating RSSO and OKTA using SAML and should be able to login to the application (Remedy Midtier) via RSSO using SAML.

 

Vid6. Shows login in of the midtier via RSSO integrated with SAML (Local OKTA user and Active Directory user) and also how to use the "user ID transformation" option in RSSO

 

OKTA Advance options

OKTA has some advanced options which you might want to make use of. In this section we will take a look at these options. In general if any of the basic or advanced options are changed you will need to re-import the OKTA's meta data into RSSO.

 

You can get to the advance options page by login into the OKTA admin console --->Admin-->Applications--->select the application--->Genral tab-->Click edit on the SAML Setting tab-->Click Next on the General settings--->Once on the SAML click show advance settings (fig)

 

Fig8. Advanced settings in OKTA

 

Response: Determines whether the SAML authentication response message is digitally signed by the IDP or not. A digital signature is required to ensure that only your IDP generated the response message. The default and recommended setting is "Signed"

 

Assertion Signature: Determines whether the SAML assertion is digitally signed or not. A digital signature is required to ensure that only your IDP generated the assertion

 

Signature Algorithm: Determines the signing algorithm used to digitally sign the SAML assertion and response

 

Digest Algorithm: Determines the digest algorithm used to digitally sign the SAML assertion and response

 

Assertion Encryption: Determines whether the SAML assertion is encrypted or not. Encryption ensures that nobody but the sender and receiver can understand the assertion

NOTE: RSSO 9.1.04 and below does not support this function. The support for Assertion Encryption is scheduled for RSSO 1805 (May 2018)

 

Authentication Context Class: Identifies the SAML authentication context class for the assertion's authentication statement

 

 

Troubleshooting OKTA SAML & RSSO

There are many ways in which authentication can break between OKTA SAML and RSSO. The following section will not describe these situation (Will show a couple of common issues), but will instead go through the best approach to troubleshoot these problems and document what files to send to BMC support if you are still not able to find a solution. If you are seeing a particular error the first step is to search the BMC support pages, knowledge base and communities. The troubleshooting steps for SAML will also be valid for a whole host of other SAML IDP such as NetScaler.

 

We'll take a look at the RSSO server logs, the OKTA system logs, Fiddler, SAML tracer and the application agent log.

 

SAML Tracer/Chrome Panel: Good tool to see SAML requests and responses from SP and IDP, limited in its functionality but is more intuitive than fiddler. At the time of writing is only available for FireFox browser its equivalent for Chrome browser is SAML Chrome Panel

 

Fiddler: Best all round tool to troubleshoot SSO related, network and sessions issue. Can be complex and some company policies will not allow fiddler to be installed as it can pose a security risk.  NOTE: Do not install fiddler on a server as it can pose a security risk because the fiddler Root certificate needs to be trusted for decryption.

 

RSSO Server Logs / Application Agent Log: All logs related to RSSO can be found in the /tomcat/logs directory of the RSSO server and its integrated web applications (Remdy Midtier, BAO, TrueSight)

 

OKTA System Logs: The OKTA system logs would be a place where you would look if its determined that a SAML response is not coming back correctly or the OKTA IDP can not process the SAML request (You'll use one of the tools above to determine this). You might not have acces to see these logs if you are not an OKTA admin, so you will need to speak to the OKTA administrator to take a look at the logs on the OKTA side.

 

If we have followed the above configuration process and are not able to login, the first thing we need to do is to looks at what the error message looks like, you can often tell very quickly what component in the process is throwing out the error message just by looking at the screen the message is being displayed on & the url in the browser, you can then start troubleshooting from that component whether its RSSO, OKTA(SAML) or the application (vid7 ).

 

Vid7. Shows how to differentiate different screens when a problem occurs so you can identify quickly where to start the troubleshooting process

 

Vid8. Shows troubleshooting with SAML tracer plugin for browser

 

Vid9. Shows how to troubleshoot sessions in fiddler

NOTE: Do not install fiddler on a server since this posses a security risk, where the fiddler certificate needs to be trusted. If you do install it on a server make sure to remove the FIDDLER certificate from the trusted certificate

 

 

 

Fig9. Fiddler icons legend

 

RSSO Server Logs / Application Agent Log

For both the RSSO server and the integrated applications (Midtier, BAO, Truesight) the RSSO related logs can be found in the /tomcat/logs directory. The majority of the time when there is a problem with the SAML login process we will need these logs in debug mode.

 

rsso.0.log - The RSSO server log found in tomcat/logs directory

rsso-agent.0.log - This is the agent log found on the integrated application in the tomcat/logs directory. The RSSO agents at most does the redirection to RSSO server and in terms of SAML authentication does not take part in the authentication process. The default RSSO agent log level should be sufficient enough for troubleshooting purposes.

 

RSSO Server Log debug - To set the RSSO server log into debug mode, login to the RSSO admin console -->General-->Basic and change the "Server Log Level" to DEBUG, there is no need to restart the RSSO tomcat service, you should start seeing debug messages in the rsso logs after 30 seconds.

 

RSSO Agent logs debug - Log level should be left at default, the RSSO agent will log most  Info, Warnings and Error messages

 

Fig10. Shows the location on the RSSO admin console to set the RSSO server to "DEBUG" switch back to "INFO" when not troubleshooting

 

 

 

Active Directory Federation Sevices (ADFS) SAML

Microsoft Active Directory Federation Services (ADFS) is an extension of Active Directory. While active directory serves to contain user identification, authentication and authorization within its own organisation and domain boundaries, its extension Federation Services can be used to cross these boundaries.

 

The basis of Federation Services is to provide a trust relationship between two organisations or entities, where one side can be used to hold user identification and the other side provides applications and resources.

 

ADFS uses a claims-based access-control authorization model to maintain application security and to implement federated identity. Claims-based authentication involves authenticating a user based on a set of claims about that user's identity contained in a trusted token. Such a token is often issued and signed by an entity that is able to authenticate the user by other means, and that is trusted by the entity doing the claims-based authentication.

 

In this section we are going to have a look at configuring SAML Authentication with RSSO using ADFS

 

Required information for ADFS SAML Configuration:

RSSO server service url: https://rssolb.bmc.com:8443/rsso (The example we will use in this post)

Service Provider Identity: RSSO (example we will use in this post)

ADFS server name

ADFS meta data either url or .xml file holding the meta data (Ask the ADFS administrator for the metadata url)

Signing certificate

 

When configuring RSSO and ADFS SAML you can either configure RSSO first or create the ADFS relying party trust, either way will work. In this post we will start by creating the relying party trust then continue to configure RSSO.

 

Creating Relying Party Trust on ADFS

To enable RSSO to use ADFS we will need to create the relying party trust for RSSO on the ADFS server. In the following video we will run through this. This is a function of the ADFS administrator, these steps should be sent to the ADFS administrator to action. You will also need to to send the ADFS administrator the Service Provider IdentityID.

The Service Provider identity ID can be configured on the RSSO admin console "General--->Advanced" tab. If you are going to configure ADFS SAML under the none default realm "*" you will need to add "/RealmName" to the SP entity ID, for example in this post our entityID is called "RSSO" but later on we will configure a realm in RSSO for SAML authentication called "ADFS" so our entityID will be "RSSO/ADFS" We do this to separate one tenant/realm/domain authentication from another  (fig11) The rest of the information on the "Advanced" tab will be configured later, but the ADFS admin will need the SP entityID to be able to create the relying party trust.

 

Fig11. shows the SP entity ID. Because we are going to create a realm for SAML ADFS called "ADFS" our SP entity ID will be "RSSO/ADFS"

 

 

Vid10. Creating relaying party trust for RSSO

 

ADFS RSSO Claims rule template

Copy the ADFS claimes rule template below for the ADSF claims rule (Fig11)

 

* Put in the ADFS server FQDN

** Put in the RSSO service provider name, if the non default "*" realm is being used, then add the "SP entity ID / Realm Name"

 

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "*<ADFS_Server_Name>/adfs/services/trust", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "**<SP_Identity_ID>");

 

Fig12. Shows ADFS claim rule for RSSO

 

Relying Party's Federation Meta Data Url

This is the location to the RSSO meta data. If you have not configured RSSO yet, you can still put this url into the "Relying Party's Federation Meta Data Url" field when creating the relying party

 

*RSSO server's FQDN

** RSSO server port number

*** If you are using the default "*" realm use "*" for the realm name, else use the realm name as defined in RSSO (fig13)

 

https://*<RSSO_SERVER_FQDN>:**<PORT>/rsso/getmetadata.jsp?tenantName=***<REALM_NAME>

 

Fig13. Shows entry of the RSSO SP meta url

 

 

Configuring RSSO (Service Provider) For ADFS

After creating the relying party trust on the ADFS server, the next step is to configure RSSO to use it. In this blog we will be creating a realm called "ADFS" in RSSO where we will be configuring SAML (ADFS) authentication.

 

Creating The Keystore and Certificate For SP Signing

Most ADFS implementations require the request to be signed by the Service Provider, you can confirm this with the ADFS administrators. The first thing we need to do is to create the keystore and certificate  on the RSSO server to use for signing the SAML request going to ADFS.  Follow the Setting SP signing certificate for SAML authentication for instructions on how to do this.

 

Configure Service Provider Options

After the keystore has been created, the next step is to configure the SP configuration on the RSSO admin console login to the console and go to General -->Advanced

In the "Service Provider" section we will fill out the the service provider information (fig13).

 

SP Entity ID: This is the unique identity of this provider, it can be any name you like, however if the relying party trust was created first then this name will need to match what was configured on the ADFS side

 

External URL:  This is the url SAML (ADFS) will respond to RSSO on, this can be considered as the external Service url. Since SAML support cross domain authentication, its recommended that this url uses SSL, so tomcat will need to be configured to use SSL.

 

TIP: Unless there is a company wide policy to use http internally then both the Service URL and the EXternal URL should be using SSL for more secure communication

 

Keystore FIle: This is the full path of the keystore which was created earlier. The full path is needed only if the keystore location is not in the "\webapps\rsso\WEB-INF\classes\" folder on the RSSO server

 

Keystore Password: Enter the password that was used when the keystore was created

 

Signing Key Alias: The alias name used when the keystore was created, the alias name is created with the "-alias sp"  parameter when creating the keystore

 

After these fields are filled out hit "Save" There is no need to restart the RSSO service after this.

 

Fig14.  The filled out information for the Service Provider with examples documented at the beginning of this post

 

 

Create New Realm For SAML ADFS

This portion is optional but, but is normally done when one RSSO server will service different customer's or organisational departments. If RSSO is configured for only one organisation then usually the default "*" will be sufficient and there is no need to create a new realm.

 

In the example of this post, when we created the relying paty trust our SP Identity was called "RSSO/ADFS", we've already put our SP name (see above) as "RSSO", now we will need to create a realm called ADFS, so the relying party trust will know which realm to call. This is useful if one RSSO server is serving multiple ADFS severs maybe from a different organisation or department. On the RSSO admin console go to "Realm--->Add Realm Button (upper right hand side)" in the general tab on the create realm screen fill out the RealmID, Application Domain & After Logout URL  (fig)

 

Realm ID: This is the unique realm name, can be anything but be aware that if you have created the relying party trust already and if RSSO will be configured in a multi realm environment then the name must match what was configured in the relying party trust

 

Application Domain: Fill out the application server's FQDN for example if your application is remedy midtier and the midtier url is https://midtier123.bmc.com:8443/arsys then the application domain will be midtier123.bmc.com. This is the same if the application is accessed via load balancer  for example if the midtier is accessed with the following url https://mymidtierLB.bmc.com/arsys  then the application domain will be mymidtierLB.bmc.com

 

After Logout URL: The logout url is used to redirect users to another url after they have logged out needs to be in http format i.e. http://www.bmc.com will take the users to BMC web page after log out

 

After filling out the above three fields go to the "Authentication" tab on the "Authentication Type" drop down list select local  then hit "Add" we will continue the rest of the configuration for ADFS authentication in the next

 

Fig15. New realm creation (Example in this post : ADFS)

Configuring SAML Authentication

The next step in this process is to create the SAML authentication, this include importing the IDP meta data, configure the User ID Attribute , select if the requests to the ADFS server needs signing and check if the SP meta data has been published correctly (vid11 )

 

Vid11. Goes through the process of creating the authentication for SAML (ADFS)

 

Parameters list

Header 1Header 2
ImportOpens a dialog box to import the IdP metadata. You can provide a URL or specify a local file to import the data.
IdPEntity ID

IdP entity ID that is obtained from an external IdP provider such as AD FS or Okta.

Examples: http://adfs.local/adfs/services/trust , http://www.okta.com/exk4mi22tbfhiAnIn0h7

Login URL

Login URL of the IdP that is obtained from an external IdP provider such as AD FS or Okta.

Examples: https://adfs.local/adfs/ls , https://dev-726770.oktapreview.com/app/bmcdev726770_oktaidp_1/exk4mi22tbfhiAnIn0h7/sso/saml

Logout URL

URL provided by IdP to which the user is redirected for SP initiated logout. If you do not provide any value in this parameter, then the value in the Login URL field is used for both login and logout endpoints.

Logout Response URLURL provided by IdP to which the user is redirected for IdP initiated logout.
HTTP Binding TypeHTTP binding for SP initiated logout URL.
IdPSigning CertificateSigning certificate that is used by Remedy SSO to sign requests that are sent to IdP.
User ID AttributeUser ID attribute that is used to retrieve the user id from the specified attribute in the SAML response. If it is not specified, the NameID will be used as the user id.
NameID Format

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.

Auth Context CompareSelect an option (exact, minimum, maximum, better) from the list.
Auth ContextAuthentication context that maps the SAMLv2-defined authentication context classes to the authentication level set for the user session for the service provider.
Auth Issuer

Issuer details that are used by SAML authentication request XML to inform the IdP about the entity ID of the service provider for this request.

If the value is not specified, by default SP entity ID of the current realm will be used as Issuer in SAML authentication request.

Assertion Time SkewTime offset between Remedy SSO and IdP. The value is specified in minutes.
Assertion Time FormatTime format used by assertions.
Sign RequestSpecifies whether the IdP requires authentication request to be signed.
Force AuthenticationThe option to select enforce authentication
Enable Single LogoutEnables SP initiated single logout, that is, if the user logs out from one application, the user gets logged out from all applications that share the same session.
Sign Response

Specifies whether Remedy SSO requires a signed response from the IdP.

Remedy SSO validates the signature from the authentication response.

Compress RequestSpecifies whether to compress the SAML message to save space in the URL.
View MetadataDisplays Remedy SSO metadata that is configured in the SP Metadata Template field. If any required parameter is not entered, the system shows an error message for that parameter.
Authentication Request TemplateTemplate used for SAML authentication request. You can select Default or Custom and also edit the template if required.
SP Metadata Template

Service provider metadata template. You can select Default or Custom and also edit the template if required.

If you are enabling the IdP initiated single logout feature, include the following information in the SP metadata template after the <AssertionConsumerService> tag and then update the settings of the IdP with the new metadata.

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="%%LOGOUT_REQUEST%%" ResponseLocation="%%LOGOUT_RESPONSE%%"/>

where,

 

 

Testing ADFS SAML Login

 

Vid12 Testing the ADFS/SAML login after configuration

 

 

ADFS Authentication Policies & RSSO configuration

ADFS provides functionality to use Windows Based Authentication (seamless login) & Form Based Authentication for users who have logged into the domain. ADFS also provides Form Based Authentication for users who are external and has not logged into using a windows account.

 

Windows Authentication: Provides seamless login functionality. If a user has logged into the domain using their windows account, ADFS will use this windows account to authenticate the user with the application e.g. Remedy Midtier or TrueSight, so users do not need to enter a user name and password. This can only be set of internal users.

 

Forms Based Authentication:  This authentication method can be used for both Internal & External users (users who have not logged into the domain with a Windows account). The Forms Authentication will request a user name and password from the user regardless of if they have logged into the domain or not.

 

In general the configuration will be Extranet is configured for Form Based Authentication & Intranet will be set to Windows Authentication  (fig15)

 

Fig15 Shows the global policies configuration for ADFS

 

When using this configuration we have to change the Authentication Context "urn:federation:authentication:windows". This will allow external users to hit the form based ADFS authentication screen (fig) while internal users will use Windows Integrated login (seamless login)  (fig16)

 

Fig16. Shows Auth Context in RSSO configuration changed to "urn:federation:authentication:windows" to allow Form Based Authentication for external user and Windows Authentication login for internal users

 

 

Fig17. Shows the Form Based Authentication Login

 

IDP Initiated Login & Single Logout

In an IdP initiated login, a user gains access to the IdP site first and then clicks on one of the services provided by the remote Service Provider (SP). After the user selects the required service, the IdP initiates the authentication process.

IdP initiated login has the following advantages:

  • In an SP initiated login, users need to use different links to gain access to different services provided by a service provider. Hence they might need to bookmark all links. The advantage of using IdP initiated login over SP initiated login is that end users need to use only one link, that is the IdP link, to gain access to any services provided by a service provider. For example, if the IdP is AD FS 3.0, the user might enter the URL https://adfs-server.contoso.com/adfs/ls/IdpInitiatedSignon.aspx to gain access to the IdP site.
  • Users get the same SSO experience for gaining access to BMC products and the third-party products as they click the same IdP link to gain access to these products.

 

IdP initiated single logout

In the IdP initiated single logout (SLO), if a user logs out from any of the applications belonging to a single login session, the user gets logged out from all applications, BMC and third-party, that belong to the same session. IdP initiated logout is triggered when the user clicks a logout option from the IdP logout page.

IdP initiated SLO has the following advantages:

  • Customers get the same logout experience for both BMC and third-party products as they click the same link on the IdP site to log out from IdP and all applications provided by different SPs that share the common SSO session.
  • When the user logs out from IdP, the user gets logged out from all other logged in applications including Remedy SSO. After logging out, if the user tries to gain access to any of the applications, the user is authenticated again.

 

Summary of steps to configure IDP initiated login & Single Logout with RSSO

  • Import IDP meta data into RSSO
  • Enable "Single Log Out" option in RSSO SAML configuration
  • Create relaying party trust for RSSO on the IDP
  • Create relay state for applications url
  • Enable Single Log Out option on the IDP

 

Vid13. goes through the process of configuring IDP initiated login and Single Logout with RSSO and ADFS

 

URLs needed for IDP initiated login and Single Logout:

 

Relay State URL: https://<RSSO Server Name>:<port>/rsso/receiver/<Realm Name>?RelayState=<Url Location>

  • RSSO Server Name: Fully qualified url of the RSSO server or the Load Balancer URL to RSSO
  • Port: Web port of the RSSO server
  • Realm Name: If creating the RSSO SAML authentication in a different realm other than the default "*"  realm, then add the realm name. If using the default "*" realm then there is no

        need to put in the realm name (see examples below)

  • URL Location: This is the redirect url you want to go to after the login to the IPD is done and session is created in RSSO.

Examples - https://rssolb.bmc.com:8443/rsso/receiver/?RelayState=https://clm-aus-022742.sso.bmc.com/rssostuff.htm    (Relay state url with the default "*" realm)

                  https://rssolb.bmc.com:8443/rsso/receiver/Myrealm?RelayState=https://clm-aus-022742.sso.bmc.com/rssostuff.htm  (Relay state url with a realm called "Myrealm")

  • Single Logout URL:  The default Single Logout URL for ADFS is https://<ADFS server name>/adfs/ls/?wa=wsignout1.0
  • ADFS server name: The server name of the ADFS server or farm name

 

Example - https://clm-aus-022742.sso.bmc.com/adfs/ls/?wa=wsignout1.0 

 

Troubleshooting SAML ADFS & RSSO

There are many ways in which authentication can break between ADFS SAML and RSSO. The following section will not describe these situation (will show a couple of common issues), but will instead go through the best approach to troubleshoot these problems and document what files to send to BMC support if you are still not able to find a solution. If you are seeing a particular error the first step is to search the BMC support pages, knowledge base and communities.

 

We'll take a look at the RSSO server logs, the ADFS system logs, Fiddler, SAML tracer and the application agent log.

 

SAML Tracer/Chrome Panel: Good tool to see SAML requests and responses from SP and IDP, limited in its functionality but is more intuitive than fiddler. At the time of writing is only available for FireFox browser its equivalent for Chrome browser is Saml Chrome Panel

 

Fiddler: Best all round tool to troubleshoot SSO related, network and sessions issue. Can be complex and some company policies will not allow fiddler to be installed as it can pose a security risk.  NOTE: Do not install fiddler on a server as it can pose a security risk because the fiddler Root certificate needs to be trusted for decryption.

 

RSSO Server Logs / Application Agent Log: All logs related to RSSO can be found in the tomcat/logs directory of the RSSO server and its integrated web applications (Remdy Midtier, BAO, TrueSight)

 

ADFS System Logs: The ADFS system logs would be a place where you would look if its determined that a SAML response is not coming back correctly (you'll use one of the tools above to determine this). You might not have acces to see these logs if you don't have access to the ADFS server you will need to speak to the ADFS admins to either have a look for error messages relating to the RSSO SP or ask for permission to view the logs.

 

If we have followed the above configuration process and are not able to login, the first thing we need to do is to look at the error message, you can often tell very quickly what component in is spitting out the error just by looking at the screen the message is being displayed on & the url in the browser, you can then start troubleshooting from that component whether its RSSO, ADFS or the application (vid13)

 

Vid13. Quick troubleshooting method identifies where to start the troubleshooting process

 

Vid14. Shows troubleshooting with SAML tracer plugin for browser

 

Vid15. Shows how to troubleshoot sessions in fiddler

NOTE: Do not install fiddler on a server since this posses a security risk, where the fiddler certificate needs to be trusted. If you do install it on a server make sure to remove the FIDDLER certificate from the trusted certificate

 

 

 

Fig Fiddler icons legend

Vid16. Shows troubleshooting with the ADFS Event Logs

 

Event Viewer Security Search By User Filter:

 

<QueryList>

<Query Id="0" Path="Security">

<Select Path="Security">* [EventData[Data[@Name='TargetUserName']='USERNAME']]</Select>

</Query>

</QueryList>

 

 

RSSO Server Logs / Application Agent Log

For both the RSSO server and the integrated applications (Midtier, BAO, Truesight) the RSSO related logs can be found in the /tomcat/logs directory. The majority of the time when there is a problem with the SAML login process we will need these logs in debug mode.

 

rsso.0.log - The RSSO server log found in tomcat/logs directory

rsso-agent.0.log - This is the agent log found on the integrated application in the tomcat/logs directory

 

RSSO Server Log debug - To set the RSSO server log into debug mode, login to the RSSO admin console -->General-->Basic and change the "Server Log Level" to DEBUG, there is no need to restart the RSSO tomcat service, you should start seeing debug messages in the rsso logs after 30 seconds.

 

RSSO Agent logs debug - Log level should be left at default, the RSSO agent will log most  Info, Warnings and Error messages

 

Fig18. Shows where to set DEBUG level for the RSSO server

 

 

 

What Logs and Information To Send BMC Support

If you come across a particular problem with RSSO & SAML authentication, when raising a case with BMC support the following details will help expedite resolution.

 

1. Version of RSSO

2. If SAML authentication has been working before and now does not, consider what may have changed in the environment, i.e. patches/network changes applied before the issue started to occur

3. Description of the problem including error messages seen (screen shot if possible)

4. RSSO server log in "DEBUG" mode, you can set this on the RSSO admin console "General Tab--->Basic" Screen the logs can then be found on the RSSO server in /tomcat/logs

generally its best to zip up all logs in this directory that has been updated from the time frame the problem occurred

5. Which IDP you are using i.e. ADFS, OKTA

6. Date/Time the problem occurred

7. A userID which is being used if its a session problem

8. Fiddler trace or SAML Tracer logs (see videos above on how to capture and export these)

 

Sometimes BMC support will need access to the IDP for further troubleshooting, so the SAML administrator maybe asked to attend a call.