Single Sign On

Contents:

• Introduction
• Benefits of Single Sign-On
• Guide to Set-up SSO Integration
  • Step 1a (optional): Provide SSO Configuration Details in a QA/Test Appen Organization
  • Step 1b: Provide SSO Configuration Details in Production Appen Organization
  • Step 2: Set-up SAML Assertion Details in IdP
    
    • Assertion Timeout
  • Adding Requesters to SSO-Enabled Organizations
  • Inviting New Requesters to SSO-Enabled Organizations
  • Additional Instructions
• IDP Application Set-up

Introduction

Benefits of Single Sign-On

1. Users have to memorize fewer passwords, thereby increasing usage and time savings.
2. All established password policies for your corporate network are in effect increasing security for users who have access to sensitive data.

Guide to Set-up SSO Integration

Step 1a (optional): Provide SSO Configuration Details in a QA/Test Appen Organization

1. Contact your Customer Success Manager or Account Executive to get access to set-up a QA SSO integration in a separate, testing Appen organization.
   • This is highly recommended to ensure the integration is successful before setting up in your Production Appen organization.
2. Let your Customer Success Manager or Account Executive know which accounts you'd like to be moved into the QA org for testing.
   • We recommend moving at least two users on the QA team. One user to become an Org Admin to set up the integration and one user to test SSO log in after SSO is set-up. 
   • This move is temporary and users can be moved back to the Production organization after QA is complete.
   • Aside from moving existing users, we can also use test accounts if customers have a testing IDP environment of their own. Customers will need to "Sign Up" with these new accounts and provide the emails to their Appen representative to move to the test SSO org.
3. Once the QA org is created and users are moved, Appen will enable the self-service Single Sign On setting.
4. The user who is setting up the integration should now see the SSO tab under their “Account” page (also shown in Figure 1 below).
5. Provide your IdP XML metadata (per instructions below - Step 1b, 2) and add assertion details in your IDP (per instructions below - Step 2).
6. Once all metadata is successfully saved on the platform and IdP, the test user account should attempt SSO login. 
   
   • SSO login can be accessed via the IdP provider if the app is added to the user’s workspace 
   • Otherwise, a user can input their email to client.appen.com with no password and the platform will redirect to the integrated IdP for sign-in.
7. If the test user can successfully sign-on, the same set-up process can be applied to the Production SSO Organization, following the steps directly below.

Step 1b: Provide SSO Configuration Details in Production Appen Organization

1. Contact your Customer Success Manager or Account Executive to get access to the capability and specify who on the organization should have Org Admin permissions to set-up SSO. 
2. In Appen, the Org Admin should navigate to their Account Page --> SSO tab.  
   
   • If you cannot find the SSO tab, please reach out to your Appen Customer Success Manager or Platform Support team.

Note: Only your Organization Admin(s) have access to set up the integration. The SSO tab will not be visible to standard users.

 

1. Provide your IdP XML metadata. You have 2 options to enter the metadata
   • Provide a URL with IdP metadata (ex: https://idp.ssocircle.com/) OR copy and paste the XML metadata in the textbox.
   • See the example below. Note: Replace ${certificate} with client certificate

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="http://www.okta.com/exk2en8uYL5E4ldZ4355">
 <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
   <md:KeyDescriptor use="signing">
     <ds:KeyInfo xmlns"http://www.w3.org/2000/09/xmldsig#">
       <ds:X509Data>
         <ds:X509Certificate>${certificate}
         </ds:X509Certificate>
       </ds:X509Data>
     </ds:KeyInfo>
   </md:KeyDescriptor>
   <md:NameIDFormat>
     urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
   </md:NameIDFormat>
   <md:NameIDFormat>
     urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
   </md:NameIDFormat>
   <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://nearsoft.okta.com/app/nearsoft_f8test_1/exk2en8uYL5E4ldZ4355/sso/saml" />
   <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://nearsoft.okta.com/app/nearsoft_f8test_1/exk2en8uYL5E4ldZ4355/sso/saml" />
 </md:IDPSSODescriptor>
</md:EntityDescriptor>

1. Provide Redirect URLs
   • Appen can optionally configure the following URLs so that users are redirected back to their corporate network when required. If you do not want redirect URLs, please enter the default Appen URL (https://client.appen.com/).
   • Important: HTTPs header is required
     • Redirect Error URL: Provide a URL the user should be redirected to when an authentication/authorization error occurs.
     • Redirect logout URL: Provide a URL the should be redirected to when the user is logged out of Appen.
2. Select the Org-level SSO mode.
   
   • Org-level (default): Only users who are in the Appenorganization associated with the customer will be able to use SSO. Other users from your company using their corporate emails to login to Appen continue to use Appen credentials, but they will not have access to the organization data or jobs.
     • Example: If Dan@company.com is part of the Appen Org named "Company", he will use SSO to access the platform. However, if tom@company.com is not part of the Appen Org named "Company", he will not be able to use the SSO but can log in using Appen credentials.
3. Go ahead and 'Save' the settings.
4. After the set-up is completed successfully, you will receive a SAML assertion template to configure in your IdP.

   

   Figure 3: SSO Settings - SAML Assertion Template

5. Copy the SAML assertion.
6. You can go back and edit your SSO set-up by clicking the edit button present in the "SSO Settings" tab.

<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="#{id}" IssueInstant="#{dateAutogeneratedFromIdP}" Version="2.0">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">#{entityId}</saml2:Issuer>
    <saml2:Subject>
        <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">${emailAddress}</saml2:NameID>
        <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml2:SubjectConfirmationData NotOnOrAfter="#{dateAutogeneratedFromIdP}" Recipient="https://client.appen.com/saml/consume?customer_name=#{ADAPOrgNameCaseSensitive}"/>
        </saml2:SubjectConfirmation>
    </saml2:Subject>
    <saml2:Conditions NotBefore="#{dateAutogeneratedFromIdP}" NotOnOrAfter="#{dateAutogeneratedFromIdP}">
        <saml2:AudienceRestriction>
            <saml2:Audience>com:figure-eight:sp</saml2:Audience>
        </saml2:AudienceRestriction>
    </saml2:Conditions>
    <saml2:AuthnStatement AuthnInstant="#{dateAutogeneratedFromIdP}">
        <saml2:AuthnContext>
            <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
        </saml2:AuthnContext>
    </saml2:AuthnStatement>
    <saml2:AttributeStatement>
        <saml2:Attribute Name="team_id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">${teamId}
            </saml2:AttributeValue>
        </saml2:Attribute>
        <saml2:Attribute Name="emailAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">${emailAddress}
            </saml2:AttributeValue>
        </saml2:Attribute>
    </saml2:AttributeStatement>
</saml2:Assertion>