Configuring your SSO (single sign-on) with Kuali

• Our Metadata
• Steps to Implement
• Attributes
• Affiliations
• Updates to SSO Metadata

If you utilize your own single sign-on at your institution you can connect that login to access Kuali products. Kuali has the ability to integrate with the following SSO (single sign-on) protocols:

• SAML (Including Shibboleth and ADFS)
• CAS (1.0 and 2.0)
• LDAP

Note: The below outlines how to configure your Institutional SSO with Kuali.  If you're an end user that is having issues logging into Kuali via your Institutional single sign-on (or need a SSO login) please reach out to your local system or identity administrators to assist you with resolving your access.

Our Metadata

Our Metadata for Kuali can found via the InCommon Service (https://www.incommon.org/).  For Build specifically, you can use: https://saas.kualibuild.com/auth/saml/meta

Steps to Implement

SAML:

• Kuali team shares our metadata with your team
• Your team will generate an Identity Provider or use an existing one.
• Your team will respond back to the Kuali team with your metadata.
  • Please be sure to include an attribute name for your ePPn (username) so we can set that.
  • If you would like to set a different attribute as the immutable attribute other than the ePPn (we know names and emails can change over time), please provide that attribute name as well.
• We will configure your metadata on our end
• Test the integration!

Note:  For SAML we have the capability to enable automatic account creation for a user when they initially login.  This will take the attributes you share on login from SAML to populate the Kuali user record.  We can set this automatic user creation to be either auto-approved or require manual approval.  When set to auto-approved it will automatically create without any review or intervention and allow the user immediate access.  When set to manual creation it will send an email to all 'admin' users to review the newly created user profile and click 'approve' to formally create the user profile and allow access for the user.  Until the Approved flag is checked in the Person record the user will be presented with the below warning when they attempt to login:

More info in the Creating and Managing Users article.

CAS:

• 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.

LDAP:

• 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.

Attributes

The following are attributes that can be passed through authentication:

First Name

We look for: givenName, givenname, or Given Name

Last Name

We look for: sn, surname, or Surname

Display Name

We look for displayName

Username

You tell us what attribute name to track for this. Some examples we often see are eduPersonPrincipalName, uid, nameID.

Email

We look for mail, officialMail, email, or E-Mail-Address

School ID

You tell us what attribute name to track for this. Some examples we often see are emplId, employeeNumber, netID.  Please note, for CAS login you must use schoolid or schoolIdto automatically map.

Affiliations - (SAML ONLY)

This is another attribute where you tell us what attribute to track. Some examples we often see are eduPersonAffiliation, groups, affiliations. We do support multiple affiliations for each user. The format we expect in those cases is to have each affiliation be a separate node in the assertion.

Note: By default any attribute you share (other than username) in your SSO to map to the Kuali User profile will update when the user logs in if the value changes or is different than what's currently set in the field for the Kuali user profile.  When these attributes get updated on login based on the shared SSO attributes it will show an update from 'kuali-system' in the User History.  We have the option of disabling this functionality so no shared values will update the user attributes.

Affiliations

Our affiliations is an optional attribute for our SAML institutions.You can set one or more affiliations to your users through SSO.In the case of multiple affilitionas for a single user, we expect the values to be separate XML nodes in your release. Please see an example below:

<saml:Attribute Name="eduPersonAffiliation"
 NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
 <saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
 <saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
 </saml:Attribute>

Each affiliation is a new <saml:AttributeValue> node. You can also set affiliations through our API. An example of this is below:

PUT /api/v1/users/<id>
Content-Type: application/json
Authorization: Bearer <token>

{
  "affiliations": [
    {
      "affiliation": "faculty",
      "orgDN": "humanities"
    }
  ]
}

Updates to SSO Metadata

SSO certificates/metadata occasionally need to be updated since they are only valid for a certain amount of time.  If your local SSO certificate is being updated you will need to reach out to us via a support ticket to start the process of updating your Kuali SSO configuration to the new metadata.  In the support ticket please provide the new metadata (provide link), or let us know if it will be updated in InCommon repository, and the expiration date of the current certificate or when you desire to transition.  If you can provide as much advanced notice prior to the expiration of the current SSO certificate that is best to allow us to make the transition successful.