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
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!
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.
- The URL - Full URL with port and protocol, Ex:
Attributes
The following are attributes that can be passed through authentication:
- First Name
-
We look for:
givenName
,givenname
, orGiven Name
- Last Name
-
We look for:
sn
,surname
, orSurname
- 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
. -
We look for
mail
,officialMail
,email
, orE-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 useschoolid
orschoolId
to 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.
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.
Comments
0 comments
Article is closed for comments.