IT Academy eLearning website resources have been claims/assertions-enabled and on-boarded to enable the Federation handshake with the institution’s identity provider. Now institutions have the capability to federate with Microsoft so Faculty, Staff and Students can sign into the IT Academy member and E-Learning instructor and student sites, using their school credentials . This allows for a single sign-on experience across ITA sites, for user with just their institution’s login credentials.
The Resource provider/Relying party on-boarding process involved claims/assertions-enabling all 3 sites for eLearning:
- IT Academy member site www.microsoftitacademy.com for the institution’s IT Academy Administrators
- Instructor eLearning LMS: http://itacademyinstructor.microsoftelearning.com (hosted by Element K)
- Student eLearning site http://itacademy.microsoftelearning.com (hosted by Element K)
and providing a unique URL (different from the WLID URL) to the federated institution’s users (educators & students), for use in the federated access.
The requirements for Federating with IT Academy include:
- Support for the following WS-Federation protocols
- Passive Requestor Profile for Token Issuance http://msdn.microsoft.com/en-us/library/bb608217.aspx
- Federation service has to expose an end-point through which AFS can communicate for the SAML request and SAML Response from IdP
- WS-Federation Passive Requestor Profile, allows AD FS to perform authentication and authorization by way of HTTP 302 and HTTP POST redirects that originate from the user’s web browser
- WS-Federation 1.2 Trust Compatibility http://msdn.microsoft.com/en-us/library/bb498017.aspx
- a single Sign-in URL endpoint
- a single Sign-Out URL endpoint
- HTTPS security on all endpoints
- a single trust per ITA institution (that provides the authentication token).
- This is a requirement of the ADFS infrastructure as it can work with with only one IdP entity-description in the metadata.
- SAML 1.1 or SAML 2.0 token formats
- Publishing Token format in Federation Metadata (shared through https URL or via metadata.xml file, for on-boarding)
- Login URL (i.e. Federation Passive Requestor URL endpoint) that is HTTPS enabled
- Name resolution to these services (DNS published to the internet)
- ADFS requires a fully qualified domain-name and cannot support the IP format of addresses
- PrivatePersonalIdentifier (Mandatory)
- Givenname (Optional)
- Surname (Optional)
- EmailAddress (Optional)
- Country (Optional)
- InstitutionName (Optional)
Note: When Optional attributes contain null, there is a) Limited Student reporting functionality for ITA Instructors and b) User support troubleshooting is more challenging.
7. An institution should have an existing identity infrastructure in-production along with a test infrastructure to ensure that the federation handshake process can be completed in a sand-box environment in a timely/agile manner, without impacting the institution’s students, educators, and staff on the production environment.
Federation is based on internet standards, yet, standards are rarely comprehensive and each implementation tends to have its own approach. The differing implementations of the standards introduce variability in the way various features work and some may break – rarely is a solution ready out-of-the-box.
- SAML token formats could contain schema design limitations – attributes and elements in the schema – resulting in schema mis-match issues. SAML 2.0 spec is huge, hence most STSs, including ADFS do not fully comply with the entire spec. When interoperating with a SAML IdPs, the process involves finding individual inbound elements that need to be modified as part of the trust setup spec.
- ADFS was certified by the Liberty Alliance on the IdP Lite, SP Lite, and eGov 1.5 SAML profiles for interoperability and makes every attempt at facilitating interoperability. The base presumption is that NameID is in the subject and XML namespaces are properly defined; beyond that there are often individual elements that need to be modified or that will not be supported on the ADFS side.
- ADFS cannot ignore unsupported attributes; there is no configuration option to allow for anything other than an error.
Resolving issues that arise during the federation handshake (due to the different dialects of the SAML implementation) will involve cooperation from institution’s technical personnel.
To partake in federation with ITA, the institution must provide a single end point providing the authentication token. This is a requirement of the ADFS infrastructure as it can take only one identity provider entity-description in the metadata.
Please direct any questions via e-mail to Acadsupp@microsoft.com, or phone at 1-800-508-8454 Monday through Friday, 6:30 a.m. to 5:30 p.m. (PST).