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:
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.
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.
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
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: ITA,IT Academy,SSO,Federation
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).