Implementing SAML 2.0 with Process Automation

  • Updated

Corporate login

SAML 2.0 is a standard that makes it possible to connect an Identity Provider that is used in a company with InRule Process Automation to achieve Single Sign On (SSO). This means that users will be able to log into Process Automation using the username and password that they have on their computers. It also allows customers to automate user synchronization from internal catalog services and Process Automation which can completely remove the need to manually add, remove, or update user accounts and details in Process Automation.

It requires that you have an Identity Provider that supports SAML 2.0 that Process Automation has built support for and that we configure the connection to Process Automation together with you as a customer. Depending on your needs, the setup can be customized in several different ways.

To get access to this feature, please read the section Implementing SAML 2.0 with InRule Process Automation for details and information on what is required and how it can be set up. 

 

How it works:

Imagine we have a user named Lisa that has a task she needs to complete in Process Automation. She has received a link from Process Automation to access the task. If her organization does not use Single Sign On (SSO), she will be redirected to the login page for Process Automation where she must enter her email address and password.  But, if her organization uses SAML she will go directly to the task. This is because the SAML will send a protocol message from the Service Provider (SP), in this case, Process Automation, to an Identity provider (IDP). The IDP is a service that can be located on the ADFS server of the organization, for example. It will look up Lisa's credentials and send them back to the SP to verify that Lisa has the right to access the task.

Implementing SAML 2.0 with InRule Process Automation

The SAML setting is available in our Professional package. Please contact our sales department if you want access to SAML.

Introduction:

SAML stands for "Security Assertion Markup Language" and allows users to log in to InRule Process Automation by using their organization's credentials, a Single Sign On. 

For a more detailed description of SAML 2.0, see Technical Overview provided by OASIS: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

The benefits of SAML 2.0:

The 3 biggest benefits to use SAML 2.0 are:

1. The user can use the same login information.  

2. Your organization controls who can log in to Process Automation.   

3. SAML 2.0 works even if you are outside your organization's network. For example, you can use your mobile phone to connect via SAML 2.0

Implementing SAML 2.0 with Process Automation:

For SAML 2.0 to work with Process Automation, you need to set up an Identity Provider (IdP) on your organization's ADFS server or equivalent server.

1. The information you need from InRule to get SAML 2.0 to work on the IdP side can be retrieved from this URL: https://login.bariumlive.com/identity/fedarationmetadata2.

Four mandatory claims/attributes need to be sent in response to InRule Process Automation:

  • UserId - A unique value for each user within the customer setup
  • Firstname - User first name
  • Lastname - User last name
  • Email - User email address. Value is also used as a username and must therefore be unique in InRule.

In addition to these claims, it is also possible to send extra claims that could be used in a Process Automation application to add information to a logged-in user.

2. The customer then needs to set up a URL to federationmetadata.xml. The URL usually looks something like this: https://adfs.customer.com/federationmetadata/2007-06/federationmetadata.xml

SAML 2.0 will not work if Process Automation does not have a URL to federationmetadata.xml. Using just the file will not work.

3. After Process Automation has retrieved the URL from the customer, InRule can start configuring SAML 2.0 setup.

4. Before InRule can activate SAML 2.0 a unique identifier for each user must be set for all existing users. This identifier can for example be an email address, a sAMAccountName, or some other unique key.

 

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.