The benefits of enabling Federated claims-enabled access to IT Academy eLearning websites/resources include

1. Single Sign-On provides access to multiple sites/resources [no additional usernames/password to be remembered /supported]
2. The institution retains control over the Student identity/PII data
3. Existing student identity at the institution can be used to access multiple benefits [there is no need to ‘sponsor’ the student for additional identities such as  WLID]
4. Automatic provisioning and de-provisioning of access to resources

The process of setting up the Federation handshake between each institution’s federated identity STSs and MSIT’s ADFS STS includes: federation infrastructure review, claims-mapping, test, training/knowledge-transfer

1. Review the institution’s current identity management infrastructure environment to assess how it will act as an identity provider to the Microsoft IT Security Token Service (MSIT STS)
2. Document assessment results and recommended approach to establishing the federated trust between the institution’s identity management infrastructure and MSIT STS.
3. Ensure the institution meets the the technical guidelines and validate that the Requirements for ITA Federation are met [such as providing a single end point providing the authentication token].
4. Ensure the institution has a test environment ready to verify the trust set up (prior to implementing this in production).
5. Communicate the SLAs, interoperability uncertainties, timelines, commitments and onboarding project work/efforts
6. Identify customer expectations (ex: data migrations) that may not be expressed; so expectations are managed upfront.
7. Engage the institution to update the IDP on-boarding information and pass it on to MSIT and MSL SE team
8. Document Security Assertion Markup Language (SAML) token attributes & element that will be passed between the institution’s identity management infrastructure and MSIT STS.
9. Facilitate the establishment of the federated trust between institution’s Identity infrastructure and MSIT STS
10. Assist the institution implement the assessment recommendations for claims-mapping
• SAML token formats often contain schema design limitations – attributes and elements  in the schema – resulting in schema mis-match issues.  SAML 2.0 spec is huge and evolving, 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.
11. Identify any gaps and fill-in with custom code in support of federation solution, to ensure the infrastructure is ready for MSIT STS integration.
• Ensure the institution has the required server software and development software Visual Studio 2010 to maintain any custom code solution deployed in support of Federation solution
12. Engage IT Academy to update the IDP on-boarding information and pass it on to MSIT and MSL SE team.
13. Coordinate between IT Academy and MSIT so they share their on-boarding info to set up the federation trust relationship.
14. Get a ITA testing account for test and production environments
15. Provide detailed testing plan that demonstrates that the solution functions properly
• Integration testing: Integration Testing focuses on the integration and interaction with external or third party components. Test cases will be based upon verifying that the functionality described in the assessment documents are working correctly.
• Production Verification testing: After deployment to production, perform verification tests replicating those performed during Integration Testing.
16. Share with SE the on-boarding info available to on-board a new EK federation URL for the ITA.
17. Share the EK e-learning sites federation URL to Customer.
18. Track Identity Provider on-boarding progress with MSIT and Customer.
19. Facilitate meetings between Customer and MSIT if there are any on-boarding issues.
20. Get sign-offs from Customer and MSIT that all of the on-boarding exit criteria has been met, post on-boarding.
21. Provide any required training and knowledge transfer so that the customer's staff is equipped to use the solution

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 and evolving, 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 and could be time consuming.

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