To use ADFS with OAuth 2.0, you must first setup AppsAnywhere as a client in ADFS.
Active Directory Federation Services (ADFS), was introduced in Windows Server 2003 R2 to help organizations set up and participate in a standards-based identity federation.
Before You Begin
Add a new OAuth ADFS form to this page
(the process for adding a new SSO method is documented in the Single Sign-On Settings page)
Fill in the standard fields found on all SSO methods, a description of each of these is documented in the Single Sign-On Settings page, in the 'Fields Common to all Methods' section.
In addition to these, you will need to complete the following fields.
Determines how and when you want your users to be presented with the Azure login
"Manual Redirect" will add a "Login with Office 365" option to the standard login form. "Automatic Redirect" will automatically redirect any user that is not already logged in straight to the Office 365 login page for authentication. "Manual and Automatic Redirect" will offer both options to the user.
We imagine most customers will wish to use "Manual and Automatic Redirect"
The "Application ID" value that you made a note of when creating the App registration in Azure
The authentication token that AppsAnywhere uses to communicate with Azure
The key you created against your App registration in Azure in the previous steps
Short Domain Name
The domain identifier for where user information can be found for users that authenticated with Azure
In order for AppsAnywhere to know which of your LDAP domains it should query for user information when they login through Azure, you should enter the short domain for your LDAP connection, ensuring that it matches one defined in AppsAnywhere
Verify certificates is set to TRUE by default
The ca cert can be placed in /data/files/oauth2/ca.crt
If this file is there, it will be used.
If one is not provided, then the cert presented by their ADFS would have to be one signed by a globally-recognised CA (i.e. not self-signed, or signed by their own internal CA)