Articles in this section

See more

Technical - Configuring SSO (single sign-on)

Avatar
Kaci
  • Updated
Follow

Overview

For single sign on (SSO) options Kuali Research provides integrations for the following authentication protocols: SAML (Including Shibboleth and ADFS), CAS (1.0 and 2.0), and LDAP. Below is a list of requirements and processes we use to integrate with other Identity Providers. 

SAML 

For SAML and other related protocols, we provide our metadata via the InCommon Service (https://www.incommon.org/), or it can be reached at https://saas1.kuali.co/auth/saml/meta2.

From you, we'll need the following:

  • Your metadata, either through InCommon or a url to your metadata which should include the public certificate to communicate with your IDP servers.
  • The ePPN (eduPersonPrincipalName) field you use in your SAML responses to identify your users. This is usually just 'eduPersonPrincipalName' but can be customized. It should be a non-changing identifier for your users.
  • Approval type - Users that sign in using your IDP will by default allowed access into the Kuali systems. We can configure this to prevent new users from accessing any Kuali system until an administrator approves the user. This can be "manual" where your administrators will be notified of new users who wish to access the system and must be approved before they can do anything. These account approval notifications will go to any user with the role of 'Admin' in Kuali Users (local url/users).  The other option is "auto" which means they will be auto approved upon successful login.
We make use of the following additional SAML attributes, and how they map to the users stored in our system:
  • email - We use mail, officialMail, email, E-Mail-Address
  • username - This is whatever is passed through via the configured ePPN field. By default we strip the @... part of the ePPN if it exists, but this can be configured to leave the ePPN alone as it is saved to the username.
  • firstName - We use givenName, Given Name
  • lastName - We use sn, surname, Surname
  • Name - We use displayName
  • schoolId - Can map any field you release to us
You may choose to omit any of those fields and populate them manually before access to the Kuali System is enabled for your users.
 
We also support a multi-campus feature where we can configure multiple IDPs to the same Kuali instance. Upon clicking the Sign In button, they will be redirected to a page where they will select an IDP. We can configure the names that show up for all of the IDPs. In this configuration setup, we will never strip the @...from the ePPN as it is required to have unique identifiers for the campuses.
 

ADFS

This is mostly the same as SAML if you've integrated with an existing SAML identity consumer such as Kuali, otherwise, it will require special instructions to be able to talk SAML:

Kuali supports Single Sign On (SSO), a process that allows users to authenticate themselves against an external Identity Provider (IdP) rather than obtaining and using a separate username and password handled by Kuali.

Under the SSO setup, Kuali can work as a Service Provider (SP) through SAML (Secure Assertion Markup Language) allowing you to provide Single Sign On (SSO) services for your domain.

What you will need, is a ADFS 2.0 Identity Provider (IdP) which will handle the sign-in process and will eventually provide the authentication credentials of your users to Kuali. The only user data that is necessary for Kuali is a unique identifier for each user, user's first name, last name and email. Kuali does not store passwords.

Step 1. ADFS 2.0 Configuration

Consider that for the current procedure, your ADFS 2.0 server is hosted in win-0sgkfmnb1t8.adatum.com. (Do not forget to replace win-0sgkfmnb1t8.adatum.com with your ADFS 2.0 server actual domain name when following this procedure).

Open the ADFS 2.0 Management through Start→Administrative Tools→ADFS 2.0 Management.

  • Right-click on Service from the left tree-view and click on Edit Federation Service Properties.


  • In the General Tab you can find the Federation Service Identifier, which is the Identity provider URL. You’ll need to send this to Kuali staff to configure. For the current procedure the Identity provider URL is http://win-0sgkfmnb1t8.adatum.com/adfs/services/trust. Check the rest values in General Tab and confirm that they match your DNS settings for your server.


  • Click on the Certificates Entry from the left tree-view, right-click on Token-Signing certificate and then click onView Certificate


  • In the Details Tab click on Copy to File and theCertificate Export Wizard launches. Click on Next, select DER encoded binary X.509 (.cer) format, and then click Next. Choose where you want to save the certificate and click on Finish.


  • Kuali requires a PEM format certificate. So you will need to convert the certificate to PEM format using any appropriate tool or even online tools such as www.sslshopper.com (https://www.sslshopper.com/ssl-converter.html). Convert the certificate from DER to PEM format. You will need it during Kuali configuration in Step 4. Keep in mind that Kuali will work with RSA certificates. DSA certificates are not supported.


Step 2. ADFS 2.0 Relying Party Trust Configuration

At this step you are going to define the Kuali endpoints in your ADFS. You can do this by importing the metadata XML provided by Kuali.

You can find The Metadata XML file at the following address:

Go to this address and download the XML file.

  • Select Relying Party Trusts from the left tree-view under the Trust Relationships,right-click on the Relying Party Trusts and click on Add Relaying party Trust. The wizard launches.


  • Click on Start and Choose Import data about the relying party from a file.Click on Browse and locate the Metadata XML file that you just downloaded.

  • Click on Next, ignore the pop-up message and type a distinctive Display Name (eg. Kuali) and click Next.

  • Select Permit all users to access the relying party and click Next to Finish.

  • On the center Column right-click on the relying part you’ve just created (eg Kuali) and the select Properties.

  • On the Advanced Tab select SHA-1 for the Secure hash algorithm and click on OK


Step 3. ADFS 2.0 Claim Rules Configuration

In order to configure a proper communication between your ADFS and Kuali, you should define the Claim Rules

  • On the center Column right-click on the relying part you’ve just created (eg Kuali) and then select Edit Claim Rules.


  • On the Issuance Transform Rules Tab click on Add Rules. The wizard launches.

  • Select Send LDAP Attribute as Claims and click on Next

  • Define the Claim rule name (eg. Get LDAP Attributes) and select Active Directory in Attribute Store. In the Mapping of LDAP attributes to outgoing claim type select the following:  LDAP Attribute: E-Mail-Addresses, Outgoing Claim Type: E-mail Address
LDAP Attribute: Given-Name, Outgoing Claim Type: Given Name
LDAP Attribute: Surname, Outgoing Claim Type: Surname
LDAP Attribute: User-Principal-Name, Outgoing Claim Type: UPN
and then click on Finish  

  • Add a second Rule following the same procedure. Select Transform an Incoming Claim and click on Next.

  • Define the Claim rule name (eg. Email to Name ID) and set Incoming claim Type as E-Mail Address (the same one from the previous rule), Outgoing claim type as Name ID and Outgoing name ID format as Email. Then click on Finish. Have in mind that the email should be defined in all users to achieve a proper communication between your ADFS and Kuali.




Step 4. Enabling SAML SSO in Kuali

From this point, Kuali staff will set up SSO for your institution using the IdP’s Metadata XML that can be found in the following URL:


Do not forget to replace win-0sgkfmnb1t8.adatum.com with the domain name of your ADFS 2.0

Send this URL to your contact at Kuali to have the Core team finish configuring SSO for your institution and you will be contacted to test it soon after. If there are any issues, we may ask for the certificate that you exported in step 1. 

 

CAS

For CAS, we require the following:

  • The SSO Base URL of your CAS service
  • Force Logout - Per the CAS protocol, upon a user logging out of the Kuali System, we can also redirect them to your CAS service and log them out as well. By default we don't have this enabled, but we can upon request.
We make use of the following CAS attributes, and how they map to the users stored in our system:
  • email - We use mail, officialMail, email, E-Mail-Address
  • username - This is whatever is passed through via the configured ePPN field. By default we strip the @... part of the ePPN if it exists, but this can be configured to leave the ePPN alone as it is saved to the username.
  • firstName - We use givenName, Given Name
  • lastName - We use sn, surname, Surname
  • Name - We use displayName
  • schoolId - We use schoolId or schoolid
 

LDAP

For LDAP we require the following:

  • The URL - Full URL with port and protocol, Ex: ldap://ldap.monsters.edu:389
  • The bindDN - Ex: cn=LDAP Search,ou=Shared Accounts,ou=accounts,dc=monsters,dc=edu
  • The bindCredentials - An account password for querying LDAP, make this a read only user, we don't need to write anything.
  • The searchBase - Ex: ou=accounts,dc=monsters,dc=edu
  • The searchFilter - Defines how to find an account in ldap. The {{username}} part is for our code replace with the username entered. The left-hand side is the equivalent username on the institution’s side. Ex. (samAccountName={{username}})
  • The user identifer - The left side of the above field. Ex. samAccountName
  • The searchAttributes - Ex. samAccountName,mail,givenName,sn,displayName
  • Whether or not we should ignore TLS errors, such as if you're using a self-signed certificate, we would ignore those types of errors that would arise.

If you would like to sync your users manually and not have them use any of the supported SSO protocols, we also allow you to load your own users, or create them manually through the interface.

In addition to the protocol specific configuration, you may also configure how long a user's Kuali session should last. By default, it is 2 weeks.

 

Related articles

Comments

0 comments

Article is closed for comments.