Shibboleth provides federated authentication technology to applications and services hosted outside of UCSB. Because Shibboleth authentication behaves somewhat differently than how you might assume an authentication would work, we strongly recommend that you read our quick primer on Shibboleth technology.

Requesting Shibboleth Service

If you'd like your application to use our federated authentication service, here's what you'll need to do:

  1. Sign up for our LDAP Customers Mailing List to make sure you get any important announcements about service updates and changes.
  2. Ensure that the application (known as a service provider - SP) supports Shibboleth authentication.
  3. Contact our Help Desk to register your app. Your request must include the following details, some of which you'll need to get from your application provider:
    Application or Service Name: What's this application known as?
    Login URL: Link provided to the end-user to access this application.
    Service Provider Entity ID: The unique identifier assigned to this SP (it should look something like a URL).
    Brief Service Description: A sentence or two about what this application provides.
    Access Requirements: Who is authorized to use this app? students, employees, selected individuals, etc.
    Authorization Mechanism: How is the above-described access managed? Affiliation lookup, internal authorization table, etc.
    UCSB Service Sponsor: Name & e-mail address of the service owner at UCSB.
    Sponsor Department Code: Not sure? Check our department list to confirm.
    UCSB Support Contact: Where we can direct our customers for post-authentication support (phone number or URL).
    Service Provider Technical Contact: Contact information for your implementation partner or vendor
    InCommon Membership: Is this vendor a member of the InCommon Federation, and if so have they registered this SP with InCommon?
    • If the answer is "no", you'll need to provide us with the Service Provider Metadata; your vendor or implementation partner can provide this for you.
    • If the answer is "yes", InCommon provides us with their metaddata so you're in the clear.
    Include in our Service Catalog: This should typically be "yes" unless the application is meant to be private.
    Required Attributes: Since they don't see the login credentials directly, the SP will need us to tell them something about an individual who has logged in. A typical SP may need the following:
    • displayName
    • ucsbCampusID
    • mail
    • eduPersonScopedAffiliation
    See our data dictionary to understand what attributes are available, and consult with your provider accordingly.
  4. We'll work with the service sponsor and technical service provider to facilitate integration.

Note that the UCSBnetID – and thus eduPersonPrincipalName – is not necessarily permanently assigned to an individual (see our information on UCSBnetID Reissue for details). If your SP must store a foreign key we recommend using the ucsbCampusID or eduPersonTargetedID. For those who must store eduPersonPrincipalName with their application (e.g. for authorization purposes) we recommend that you sign up for our UCSBnetID Reissue Notification mailing list so that you can be notified when such changes occur. Contact our help desk for further information.