The table below provides additional information on what ADFS can do versus what it cannot do with a requesting party's application.
What ADFS Does | What ADFS Does Not Do |
ADFS allows trusted federated partners to authenticate using DOI Active directory. | ADFS does not provide authentication services to trusted partners without SAML 2.0 compliant applications. |
ADFS provides Web SSO to federated partners, which enables Requesting Parties’ users to have an SSO experience to access their web-based applications/systems. | ADFS does not extend the schema for Active Directory to create additional custom attributes in AD for the sole purpose of using them as claims. |
ADFS defines Claims in terms that each partner understands and appropriately maps in the ADFS trust policy for exchange between federation partners, such as LDAP attributes. | ADFS does not authorize users. The DOI uses ADFS to authenticate users. Requesting Parties are responsible for authorizing users for their systems and applications. |
ADFS provides an extensible architecture for claim augmentation. For example, it adds or modifies claims using custom business logic during claims processing. | ADFS does not allow any Non-Secure Hash Algorithm (SHA256) to utilize ADFS authentication service for their applications and systems. |
ADFS provides the capability to manage one set of credentials for multiple applications and systems. | ADFS does not allow other authentication protocols, such as LDAP. |
ADFS provides authentication services to trusted partners with SAML 2.0 compliant applications. | ADFS does not allow IDP initiated SSO |
ADFS allows SP initiated SSO | Provide access to accounts in or authentication to any AD forest other than net |
Provide access to all doi user accounts for authentication. | Provide access to authenticate using elevated or privileged accounts |
Provide access to authenticate using any doi standard user account |