Sponsored Guest SSO Integration

The CalNet Sponsored Guest service allows external users to log into campus applications using their personal Google/Gmail credentials. To enable this for your application, guests must be invited by a UC Berkeley employee (sponsor). Once the invitation is accepted, a guest account is created in the CalNet directory.

How to Allow Sponsored Guest Access to Your Application

1. Modify your CAS Service: Submit an SSO Service Request in ServiceNow to update your existing CAS definition. Include the following details:
   • Service Name: Your application name.
   • Service URL: Your application's CAS URL.
   • Description of Changes: Include your LDAP bind account and specifically note that you want to enable access for Sponsored Guests.
2. Update Your Application Code: Ensure your lookup filters, LDAP calls, and authorization logic specifically reference:
   • berkeleyEduAffiliations = GUEST-TYPE-SPONSORED
   • The Guests OU (ou=guests,dc=berkeley,dc=edu).

---

CalNet Configuration Steps

Upon receiving your request, the CalNet team will perform the following actions:

• Service Specificity: Ensure your CAS service definition is specific to your application (moving away from any default wildcard definitions).
• Authorization Update: Update the definition to allow GUEST-TYPE-SPONSORED.
• UI Theme: Update your service to use the "cirrus" CAS theme, which includes the required "Sponsored Guest Sign In" link on the login page.
• Bind Access: Update your application's LDAP bind account to grant permissions to the Guests OU if necessary.

---

Technical Specifications for Sponsored Guests

• No CalNetID: Sponsored Guests do not have a standard CalNetID. They are identified by their CalNet UID.
• Principal String: The berkeleyEduKerberosPrincipalString attribute for guests follows the format: uidNNNNNNN (where NNN is the UID value).
• Shared Sponsorship: Guest accounts can be sponsored by multiple employees. If one sponsor expires a guest but another extends them, the guest remains active. Application owners must actively manage internal authorization for these users.

Example: Guest Attributes in LDAP

dn: uid=NNNNNNN,ou=guests,dc=berkeley,dc=edu
objectClass: berkeleyEduPerson
objectClass: eduPerson
objectClass: inetOrgPerson
cn: Guest, MyUCB
sn: Guest
uid: NNNNNNN
berkeleyEduKerberosPrincipalString: uidNNNNNNN
mail: guest-email@gmail.com
berkeleyEduAffiliations: GUEST-TYPE-SPONSORED
berkeleyEduGuestSponsorUid: nnnnnnn (UID of the most recent sponsor)
displayName: MyUCB Guest
ou: guests