ADFS with EasyTerritory: Cloud-Hosted


Executive Overview:

EasyTerritory supports Active Directory Federation Services (ADFS) capability.  ADFS is a single-sign-on feature that enables a user to login to the EasyTerritory application through his company’s identity provider (IdP).  The IdP will authenticate the user using Active Directory credentials and direct him to EasyTerritory to access the application.

Advantages:

The advantages of leveraging ADFS with your EasyTerritory application are:

  • – Simple streamlined SSO access to your EasyTerritory application through company’s IdP portal.
  • – Strengthens security with users not needing to remember additional usernames and passwords.
  • – Ability for companies to control users’ access to EasyTerritory within their active directory.

Technical Overview:

EasyTerritory supports ADFS with the SAML (Security Assertion Markup Language) XML framework for authenticating users who are wanting to connect to EasyTerritory.

It is important to note that EasyTerritory’s SAML configuration is Ipd-Initiated, which means when a user attempts to browse to EasyTerritory they will be redirected to his company’s IdP sign-on page.

When a user is authenticated through his IdP, a token will be sent to the EasyTerritory servers. EasyTerritory will receive the token and grant access based on the credentials and authenticity of the claims in the token.

Client-Side Configuration:

These are details for setting up adfs on your active directory servers.

  • The information you will need when setting up the trust:
    •  – Relying Party’s identifiers:
      • https://apps.easyterritory.com/Your EZT instance GUID here/APP/
    • – SAML consumer Endpoints:
      • https://apps.easyterritory.com/YourEasyTerritory GUID here/APP/AuthServices/Acs
        • This uri will redirect you after you have been authenticated by your IdP.
  • Claims:
    • EasyTerritory requires a username, first name, last name and email when authenticating claims that are sent. These claims must match on your server and EasyTerritory’s server.  You can decide what to call the claims, but those claims must be sent to an EasyTerritory administrator. Please note that there are two alternatives for userNameClaim and emailClaim.
      • Here are some examples:
        • – User Name Claim:
        • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name,http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
        • – First Name Claim:
        • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
        • – Last Name Claim:
        • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
        • – Email Claim:
        • http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress,http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
  • ADFS server URI’s
    • Information an EasyTerritory administrator will need when configuring your EasyTerritory application are entity Id, the sign-on URL, and logout URL. Here are some examples.
      • – Server’s entity Id:
        • http://your ADFS server/adfs/services/trust
      • – IdP sign- on URL:
        • https://your ADFS server/adfs/ls/idpinitiatedsignon.aspx?loginToRP=[we put the EZT URL here, as we use that as OUR entity ID]
      • – Log out URL:
        • https://your ADFS server/adfs/ls/?wa=wsignout1.0
      • We also need to know whether you need EasyTerritory to generate logout requests (and if so, whether you want them signed) or whether we can simply redirect to the bare logout URL (which is the more common scenario).
  • Certificate:
    • In order to authenticate the claims sent to EasyTerritory, EasyTerritory will need a signing certificate.
    • If your ADFS is publicly exposed we can generate a certificate from your metadata endpoint. In this case you would need to send an EasyTerritory administrator you metadata URL.  Here is an example:
      • https://your ADFS server/federationmetadata/2007-06/federationmetadata.xml

 

Please understand we are not ADFS administrators. We may be able to give you some support with setting up a trust, but ideally your staff will be knowledgeable about this and we will not be involved with AD Federation configuration on your end.