SSO Overview
StudentForms uses Identity Federation to support single sign-on (SSO) across disparate client systems. Supported protocols include WS-Federation, SAML 2.0 (passive authentication), and CAS.
Clients who wish to implement SSO must provide the corresponding metadata of their Identity Provider (IdP) implementation. Metadata may be communicated via metadata service endpoints/urls. Alternatively, metadata may also be exchanged manually. Refer to http://en.wikipedia.org/wiki/SAML_2.0 for SAML 2.0 IdP metadata details.
Implementation
Implementers of WS-Federation or SAML 2.0 must provide the claims outlined within Client SSO Claims Requirements. Implementers of CAS Server must provide CAS attributes outlined within CAS Extended Attributes.
Implementers must provide a student test account and a school user test account for each environment (production and non-production). These accounts are required by CampusLogic for initial integration testing, maintenance, and support.
Frequently Asked Questions
What federated identity solutions have you integrated with?
As noted above, we can integrate with federated identity solutions that support WS-Federation, or, SAML 2.0. We have found that institutions that leverage open source technology in their enterprise use Shibboleth (2.0 or greater). Clients that are more Microsoft-centric, with existing investment in Windows Server 20NN, will find a more natural fit with Active Directory Federation Services (ADFS).
Can I use LDAP?
As noted above, SSO integration with CampusLogic requires a product that supports identity federation. LDAP is a feasible for internal SSO implementations but not for cross-domain, cross-company access. Use LDAP in conjunction with a federated identity solution such as Shibboleth (2.0 or greater) or ADFS.