Deep Links
Deep Links - Extending your secure SAML authentication to other applications
Deep Links allow you to extend your Centralpoint authentication with SAML, allowing one click access to other applications your end users may need to access (without having to log in repeatedly). Deep links broker the initial authentication with SAML, and empower you to pass secure tokens to other systems. Deep Links is similar to the former Microsoft Passport, allowing one user's credentials to give them access to all applications once logged in. Deep Links empower your organization to oversee an ACL, Active Control List, granting certain roles, full access to back office applications. In order to create a new record in the Deep Links module log into the console then click on Admin followed by Deep Links. Here you will see the normal module view for Deep Links you can click on NEW button in order to navigate to the add new form to create the record.
Once in the form you will have to fill out required information.
- Title – This is just the title of the record. This will have no bearing on the connection. It is for you to be able to identify the connection on your own terms.
- Deep Link Options – To create a SAML 2.0 record please select the “SSO SAML 2.0” option. Once this is selected many more options will appear for you to fill out.
- SAML Name – This will serve as the agreed upon name of the third party vendor. Most likely they will already have something setup and will provide you with this information. This will be used to properly identify the requests coming from the third party which will then enable our system to use the other proper configuration options for this established connection. This field is required.
- SAML Description – This is just a description of the established connection. It is here in order to give you more context if needed about the SAML connection being established. This is an optional field.
- SAML Auth Request Signed – Specifies whether the authentication request from the partner service provider should be signed. This field is required and the default value is No.
- SAML Sign Response – Specifies whether SAML responses sent to the partner service should be signed. This field is required and the default value is Yes.
- SAML Sign Assertion – Specifies whether SAML assertions sent to the partner service provider should be signed. This field is required and the default value is No.
- SAML Encrypt Assertion – Specifies whether SAML assertions sent to the partner service provider should be signed. This field is required and the default value is No.
- SAMLAssertionPartnerCert – this field is only used when we encrypting the assertion. This is a file upload field where you are to upload the certificate the partner is wanting to use for encryption. Please note that this file should be coming from the third party as they need to key in order to decrypt the data being passed.
- SAML Assertion URL – this is URL provided by the third party where we should be sending the SAML assertion to.
- SAML Relay State – If the third party uses relay states to dictate where in their system the user whom is attempting to get into their system is to be navigated to this is the property to place in that URL they will provide. This field can be entered as a hard coded value or as a CpScript in order to accommodate custom logic which may be needed if certain users need to go directed to a specific page while other users to another. This is an optional field and not all SAML connections will use this field.
- SAML Response Attributes – This attribute will accept XML data formatted just like you would for the Field Map for Users in the Forms module. But you will not be able to use the Form State CpScript to grab the values for the attributes. Instead you will have to use the User Info CpScript. The list of attributes required is dependent upon what the third party you are connecting to requires to load up the appropriate user in their system. Please notes the systemName attribute of the attribute element will be the name of the field as described by the third party. For instance, they might call a field First Name while in Central Point it is called Contact First Name. Example of data for this property: <attribute systemName="UserName"> <![CDATA[ [cp:scripting key=' UserInfo' attributesystemname='UserName Field' /] ]]></attribute> <attribute systemName="Email"> <![CDATA[ [cp:scripting key=' UserInfo' attributesystemname ='Email' /] ]]></attribute>
If this is your first time setting up a SAML 2.0 connection, then you will have to also configure the Module Properties. These properties will setup your Central Point as the Identity Provider (IdP) for this SAML Connection. In here you will see the following options used for the SAML 2.0 portion of the Deep Links module. The properties here will serve two separate purposes the first group of optional properties will build a client.xml file which you can share with the third party to help assist in the building of the SAML connection.
Type of certificates supported
Using SSO SAML 2.0 Connecting from Central Point to third Party (Identity Provider initiated)
This is the normal circumstance for general usage of the SAML connection whereas a Centralpoint user has access to a third party via a link inside of central point and is logged in seamlessly via the SAML protocols into the third party’s system.
Once you have configured the module and created your SAML 2.0 record you can access the record again at which point in time the CpScript property will be filled. This generated CpScript will provide a link to the webpage which will be used in order to navigate to the page for the initialization of the SAML connection building the SAML data and sending it to the third party page. From there the third party will read the assertion and attempt to match up with a user in their system. If successful it will then navigate you to a page based on their internal system or the page dictated by the relay state property if they build their system around that. This Cp script will specifically return the link to the page with the dataId of the record we are connecting to EX:
/Modules/DeepLinks/SAML2/InitSSO.aspx?dataId= DataId of record from module here.
From here you can make this a link or whatever you need it to be to fit your needs. You can add in the Format property to the CpScript in order to have it formatted the way you want within the CpScript call itself as well.
Once the script is linked properly on a page or a navigation item. A user whom has to be logged in can click on the link in order to gain access to the third party system.
Using SSO SAML 2.0 logging in from third party site via Centralpoint login information (Service Provider initiated)
Used to log into a third party’s site using your login information from Centralpoint. Think about it like using your Facebook login in order to login into a different company’s website.
Centralpoint has a special page which serves as a listener for the SAML connection. You will have to give the page to the third party so that they can configure their side accordingly. The page is located at Modules/DeepLinks/SAML2/SSOService.aspx upon connecting to this page the third part will send over a request for SAML assertion data. Upon reading this data Centralpoint will lookup data setup inside of our system based upon the SAML Name that is setup in the Deep Link module record. From there Centralpoint will look up the proper module record and build the SAML assertion using the user data logged into Centralpoint. Upon receiving the SAML assertion the third party will then look up and compare against the data in their system in order to login them into the site automatically using their Centralpoint’s active user session.
Using a Custom Deep Link