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:

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:

      1. Support for the following WS-Federation protocols
      2. End point requirements
        • 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.
      3. Token formats
        • 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)
      4. Enduser login mechanism
        • 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
      5. Client browser support for Cookies and JavaScript [i.e. cookies and JavaScript should be enabled on Student browsers]
      6. Support for following Claim Types: (Schema of the Claim)
        • 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.

Note for Passive Requestor Profile: The configuration of AD FS does not always require direct communication between all servers running AD FS components. For example, in a WebSSO configuration that relies on the WS-Federation Passive Requestor Profile, the federation service running at the Claims Provider does not communicate directly with the FS installed at the Relying Party, irrespective of whether the communication is taking place between separate organizations, or within a single organization.   There are other scenarios in which direct communication between federation servers is required, such as in the exchange of federation metadata, or when configuring SAML 2.0 to use artifact resolution.

Passive profile is a binding of WS-Federation/WS-Trust which works with browsers. This differentiates it more from Liberty in that we have a single model which can be manifested different ways and supports the design centers of the Web Services security model.

A passive requestor does not necessarily understand how to work with claims, and is passively requesting a security token.  Example: A web browser is redirected, and the redirect contains a sign-in request to a security token server (STS). The browser is the passive requestor.

A binding of WS-Federation & WS-Trust for browser clients

  • Indirectly acquire tokens via HTTP msgs
    • Pure redirect with GET
    • URL-only
    • POST body
  • Uses redirection to effect messages
    • Tunnels WS-Trust requests in app traffic
  • Requires secure transport (HTTPS)
    • Client cannot provide “proof of possession”

An active requestor is claims-aware, and actively requests a security token by building its own request and sending it to the STS.  Example: A Windows Communication Foundation (WCF) client application collects user credentials and actively sends a token request to a STS. The WCF client is the active requestor.

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).

Technorati Tags: ,,,