ADP Federation Handbook V1 8

INTERNATIONAL PRODUCTION CENTER
ADP Federation Handbook
V1.8 ► February 2017
Confidentiality: ADP
The information contained in this document is privileged and
confidential, and remains the intellectual property of ADP. This
document must be kept strictly confidential at all times. It must
not be disclosed to any person other than on a business need to
know basis.
ADP and the ADP logo are registered trademarks of ADP, LLC. ADP – A more human resource is a service mark of ADP, LLC. Copyright © 2015 ADP, LLC. adp.com
ADP Federation handbook
V1.8 ► ► February 2017
Table of Content
1. INTRODUCTION 4
1.1. Overview 4
1.2. Single Sign On principle 6
1.2.a. System entities 6
1.2.b. Authentication / authorization use case : « post » binding profile 7
1.2.c. Access to ADP application 8
2. ADP CUSTOMER REQUIREMENT 9
2.1. X.509 V3 Digital certificate – ADP customer authentication 9

2.2. SAML assertion generation 10
2.3. End user authentication 13
2.4. ADP federation service URL integration within corporate portal 13
2.5. Web Browser Requirement 14
3. TESTING ENVIRONMENT 15
4. END USER MANAGEMENT 17
4.1. UIDMT Synchronization 17

4.1.a. ADP Security database synchronization using a dynamic end user registration: 17
4.1.b. Security database synchronization using ADP user management tools 18
4.1.c. Security database synchronization using ADP Application 18
4.2. ADP password management 18
5. KEY POINTS FOR SETTING UP FEDERATION WITH ADP 19
5.1. SAML Scenario 19

5.2. SSO Servers Clock Synchronization 19
5.3. SAML Response Signing 19
5.4. X509 cert Exchange 19
5.5. SSO Authentication Mode 19
5.5.a. Mixed SSO: 20
5.5.b. SSO Only: 20
ANNEX 21
METADATA 21
QA/Test Environment 21
Production Environment 21
ADP Security database synchronization during SETUP : UIDMT batch mode management 22
Self registration example 23
Self Registration 25
2
Description
Title ADP Federation handbook V1.7
Version 1.7 February 2016
Distribution list
Recipient Entity
CUSTOMER SSO ADP
Modifications follow up table
Version Date Author Status Validator Modification details

1.0 28/07/2008 NLE DRAFT Document creation
1.1 05/08/2008 FWR DRAFT Apply FR BU Document Style
1.2 19/12/2008 NLE Stable release
1.3 05/01/2009 NLE Stable release Modifications following doc revue
05/01/2009
1.4 03/02/2009 NLE Stable release Modifications §3.4 et §3.8
1.5 23/06/2009 NLE Stable release English translation
1.6 08/12/2010 NLE Stable release Align on SAML 2.0 spec for
canonicalization method
(exclusive).
1.7 2016/02/05 NLE/SMD,FWR/DCU Stable release 2016 Infrastructure update.
Document refactoring.
1.8 2017/0228 NLE Stable Release Update figures 7,8 and 9
3
1. INTRODUCTION
1.1. Overview
In its current service production model, ADP provides customer end user authentication and therefore is acting as an
“Identity Provider” in addition of its “Service Provider” business and role.
The ADP Customer SSO functionality aims at distinguishing the “Identity Provider” role from the “Service Provider” role
by leveraging a standard interface between those two roles.
This will lead to:

• Simplify end users management process.
• Increase the access management security level.
• Drastically improve the usability and adoption of ADP solutions by end users.
In the proposed business model, ADP ensure the “service provider role” while ADP customers ensure the “identity
provider role”.
The interface between those two roles is based on the SAML protocol defined by the OASIS consortium:
https://www.oasis-open.org/specs/index.php#saml
All the technical and conceptual documentation concerning Federation Services and SAML protocol is available at the
official SAML web site: http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip
The SAML standard defined many but still limited numbers of possible combinations putting in relationship:
• The profile type used,
• The type and direction of exchanged messages,
• The transport layer used for message exchanges.
4
The table below shows all the scenarios covered by SAML 2.0 Specification and the one implemented by ADP
(highlighted).
ADP committed to implement a « WEB SSO Browser Post Profile » initiated by the identity provider (IDP).
Within this implementation commitment, ADP provides all human and technical resources that ensure the SAML
Standard compliancy and the service level expected by ADP customers.
In counterpart, ADP customer commits to respect the technical Requirement expressed in the present document.
Any modification within technical implementation of one of the 2 contractors that would affect the other should first be
notified in order to guaranty the systems interoperability.
Figure 1 ADP federation scope
5
1.2. Single Sign On principle
1.2.a. System entities
The SSO scenario is based on the SAML 2.0 standard « SAML web browser SSO profile – IDP initiated SSO : post
Binding »
(http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf §5.1.4) ,as shown in
the following diagram :
1 – The end user authenticates in its intranet portal.

2 – The end user click on the hyperlink that represents the ADP application, as a response, the web browser received a
SAML assertion in a HTML POST document to the ADP SSO Gateway.
3 – The web browser post the signed SAML assertion to the ADP SSO Gateway, the assertion is verified (digital
signature + time stamps).
4 - Security attributes are correlated and request headers are added.
5 - If the SAML assertion is verified, the ADP Federation Service Gateway sets a security cookie and redirect the end
user to the ADP application URL of the ADP service he wish to access.
6 - The end user request run through ADP reverse proxy up to ADP backend application server thanks to the ADP
security cookie.
6
1.2.b. Authentication / authorization use case : « post » binding profile
Figure 3 Post binding
This use case shows the initial process step: Authentication / authorization.
Since this authentication / authorization step is completed, the end user browser received a session security cookie
included into an HTTPS response and is re-directed to the ADP application URL (see §2.5 Web browser requirement).
7
1.2.c. Access to ADP application
The end user browser should send back this ADP session cookie with any request to the ADP application.
Any request to the ADP application will go through a reverse proxy. This reverse proxy will validate the ADP application
access (authorization) based on the session security cookie and the ADP policy Server.
Figure 4 ADP access sequence diagram
If a request is address to an ADP application without a valid ADP session cookie the reverse proxy will
intercept the request and display a “forbidden access page”. This error page will also propose to the end user
to close the browser window in order to come back to its intranet portal. Therefore we recommend that intranet
portal open ADP application in a dedicated browser window.
8
2. ADP CUSTOMER REQUIREMENT
2.1. X.509 V3 Digital certificate – ADP customer authentication
• ADP customer will provide ADP with its X.509 V3 Digital certificate public key. This public key will be use to validate
the SAML assertion digital signatures. This validation step guaranties the SAML assertion issuer as well as the assertion
integrity.
Despite the fact that this authentication scheme is more reliable than traditional “login/password” one, it is based on the
security of the ADP customer certificate private key.
ADP cannot be responsible of any security issue due to endanger of one of its customer X.509 V3 certificate private key.
In case of certificate revocation, ADP customer should notify ADP using a dedicated postal mail.
• The X.509 V3 digital certificate public key will be provided to ADP using PEM format (base 64 encoded text file).
• X.509 V3 certificate with a public key length greater or equal to 2048 (attribute SubjectPublicKeyBitLength of
the certificate). ADP recommend for the key two years life time.
• ADP customer certificate must include the following usages (attribute keyUsage of the certificate):Digital Signature
ADP recommends the use of RSA and SHA algorithms (attributes SubjectPublicKeyAlgorithm=rsaEncryption and
SignatureAlgorithm=sha1WithRSAEncryption of the certificate).
• The certificate attribute “SerialNumber” is used by ADP in order to uniquely identify ADP customer certificates. Its
value must therefore be unique (Public CA ensure such uniqueness).
• The certificate attribute “Subject” is used by ADP to recognize ADP customer. Its value should therefore reflect ADP
customer corporate name. For example:”C=FR, ST=Haute Garonne, L=Toulouse, O=ADP, OU=ADP EHC,
CN=AcmeCorp Test EHC, emailAddress=nicolas.laigle@europe.adp.com “.
-----BEGIN CERTIFICATE-----
MIIE7jCCA9agAwIBAgIJAOs3efKzWxKJMA0GCSqGSIb3DQEBBAUAMIGqMQswCQYD
VQQGEwJGUjEMMAoGA1UECBMDSURGMQ4wDAYDVQQHEwVQYXJpczEVMBMGA1UEChMM
VGVzdCBDb21wYW55MRYwFAYDVQQLEw1Qb2MgRGF0YVBvd2VyMSQwIgYDVQQDExtU
ZXN0IENsaWVudCAxIFBvYyBEYXRhUG93ZXIxKDAmBgkqhkiG9w0BCQEWGW5pY29s
YXMubGFpZ2xlQGZyLmFkcC5jb20wHhcNMDgwMjI2MTU1MzU4WhcNMTEwMjI1MTU1
MzU4WjCBqjELMAkGA1UEBhMCRlIxDDAKBgNVBAgTA0lERjEOMAwGA1UEBxMFUGFy
aXMxFTATBgNVBAoTDFRlc3QgQ29tcGFueTEWMBQGA1UECxMNUG9jIERhdGFQb3dl
cjEkMCIGA1UEAxMbVGVzdCBDbGllbnQgMSBQb2MgRGF0YVBvd2VyMSgwJgYJKoZI
hvcNAQkBFhluaWNvbGFzLmxhaWdsZUBmci5hZHAuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEA0MPlbM/ExxiJErDDyIze48R47bpLklCgcvTrQAfG
0PjVMDgPFvmGq/ZDSz0woa8agWctAPiydtLmVzXbniQgPy05tW99CGDkLTThQoHw
NKC7whmgY/DRBzPHWCTITnRRgdlEo7pYQ0BSHe/tBkLQeYRY4nkCtgPpQ5kx04FY
2WHCsoqf36kvX0a9X55kVoFfX7Dxn638i86oj7R6WlPxEn2UbmZyvtKLwEnp2lQe
Rl2sTIdhh43jWg0cGUB/dUVGTx+gB0/VcljW2XJHDrrY868uYrvpClTDab+wuOPs
a1BPKtb8D0WbXKMxGA5KH9zDjwVL9m9c9KZiSjF3fVN7gQIDAQABo4IBEzCCAQ8w
HQYDVR0OBBYEFKqGLYhJ5TS2sUQWHkWpW8qnPj4LMIHfBgNVHSMEgdcwgdSAFKqG
LYhJ5TS2sUQWHkWpW8qnPj4LoYGwpIGtMIGqMQswCQYDVQQGEwJGUjEMMAoGA1UE
CBMDSURGMQ4wDAYDVQQHEwVQYXJpczEVMBMGA1UEChMMVGVzdCBDb21wYW55MRYw
FAYDVQQLEw1Qb2MgRGF0YVBvd2VyMSQwIgYDVQQDExtUZXN0IENsaWVudCAxIFBv
YyBEYXRhUG93ZXIxKDAmBgkqhkiG9w0BCQEWGW5pY29sYXMubGFpZ2xlQGZyLmFk
cC5jb22CCQDrN3nys1sSiTAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4IB
AQB7/3hstPKsjksYnphFhaYt5dgCFt8YY7SlzfiI7jcLcy0lFS2aXwWl6o3ik7Wu
pVkwLJDBRXKXbf6//MQqLifcjU63iHWqDq4FQYw4W3NwEm0b1v6wmSj359p7z0RC
Y3SotZPquaHldOBe9tQPbm3f3ExawWzMl6Cmf6JAEN+vc4ALdAXmVwnYbZfvXxwU
LFu06V8pxq1s79dumxR9Rc+8OyLOThqwhiD45FRE12v6fMuPk7CMZSG3zIjWDI77
TdeegLqRFhRO7VxW7kJTDIEyyIpn+dQznjnnGu2aOahuaOM/UjqvRsmpZi4TK1vw
q0h+wQX/MhOe+YSgwXYnaNTR
-----END CERTIFICATE-----
Figure 5 PEM file for X.509 V3 digital certificate
9
2.2. SAML assertion generation
Identity information exchange is based on the SAML protocol. ADP customer that access the Federation Service
Gateway has to generate a POST HTML request containing a base 64 encoded SAML 2.0 response with embedded
SAML assertion.
• The “POST” HTML request has to be sent to the federation Service Gateway using HTTPS transport protocol.
• The “POST” HTML request parameter that contains the “SAML 2.0 response” is a “hidden” parameter named
“SAMLResponse “. Its value is base64 encoded in order to avoid any encoding issue during transport.
HTML/HTTPS “POST” example (as generated by customer corporate portal, base 64 encoded):
XML and HTML mandatory attributes are highlighted.
<html xmlns:adp=http://adp-gsi.com/ns>
<head>
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="-1" />
<title>ADP-GSI Federation Service SAML 2.0 Assertion Generator</title>
</head>
<body onLoad="document.forms[0].submit();">
<form method="post" action="https://sso.dev.ehc.adp.com/samlsp/">
<input type="hidden" name="SAMLResponse"value="PHNhbWxwOlJlc3BvbnNlIHZlcnNpb249IjIuMCIgSUQ9IjEyMzQiIElzc3VlSW5zdGFudD0iMjAxMC0xMi0wOFQxMjo1MzowMloiIHhtbG5zOnNhbWxw
PSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIHhtbG5zOnNhbWwyPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj48c2FtbHA6U3RhdHVzIHZhbHVlPS
JzYW1scDpTdWNjZXNzIi8+PHNhbWwyOkFzc2VydGlvbiBWZXJzaW9uPSIyLjAiIElzc3VlSW5zdGFudD0iMjAxMC0xMi0wOFQxMjo1MzowMloiPjxzYW1sMjpJc3N1ZXIgeG1sbnM6c29hcGVudj0iaHR0c
DovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPkFjbWUgQ29ycDwvc2FtbDI6SXNzdWVyPjxzYW1sMjpTdWJqZWN0IHhtbG5zOnNvYXBlbnY9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYX
Aub3JnL3NvYXAvZW52ZWxvcGUvIj48c2FtbDI6TmFtZUlEIEZvcm1hdD0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6MS4xOm5hbWVpZC1mb3JtYXQ6dW5zcGVjaWZpZWQiPm5sYWlnbGU8L3NhbW
wyOk5hbWVJRD48c2FtbDI6U3ViamVjdENvbmZpcm1hdGlvbiBNZXRob2Q9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpjbTpiZWFyZXIiPjxzYW1sMjpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YS
BOb3RCZWZvcmU9IjIwMTAtMTItMDhUMTI6NDg6MDJaIiBOb3RPbk9yQWZ0ZXI9IjIwMTAtMTItMDhUMTM6MDM6MDJaIi8+PC9zYW1sMjpTdWJqZWN0Q29uZmlybWF0aW9uPjwvc2FtbDI6U3ViamVj
dD48c2FtbDI6Q29uZGl0aW9ucyBOb3RCZWZvcmU9IjIwMTAtMTItMDhUMTI6NDg6MDJaIiBOb3RPbk9yQWZ0ZXI9IjIwMTAtMTItMDhUMTM6MDM6MDJaIiB4bWxuczpzb2FwZW52PSJodHRwOi8vc2
NoZW1hcy54bWxzb2FwLm9yZy9zb2FwL2VudmVsb3BlLyIvPjxzYW1sMjpBdXRoblN0YXRlbWVudCBBdXRobkluc3RhbnQ9IjIwMTAtMTItMDhUMTI6NTM6MDJaIiBTZXNzaW9uTm90T25PckFmdGVyP
SIyMDEwLTEyLTA4VDEzOjAzOjAyWiIgeG1sbnM6c29hcGVudj0iaHR0cDovL3NjaGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPjxzYW1sMjpTdWJqZWN0TG9jYWxpdHkgQWRkcmVzcz0iQ
WNtZV9Db3JwX1NBTUxfQXV0aGVudGljYXRpb24iLz48c2FtbDI6QXV0aG5Db250ZXh0PjxzYW1sMjpBdXRobkNvbnRleHRDbGFzc1JlZj51cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xh
c3Nlczp1bnNwZWNpZmllZDwvc2FtbDI6QXV0aG5Db250ZXh0Q2xhc3NSZWY+PC9zYW1sMjpBdXRobkNvbnRleHQ+PC9zYW1sMjpBdXRoblN0YXRlbWVudD48c2FtbDI6QXR0cmlidXRlU3RhdGVtZW
50PjxzYW1sMjpBdHRyaWJ1dGUgTmFtZT0iQXBwbGljYXRpb25JRCI+PHNhbWwyOkF0dHJpYnV0ZVZhbHVlPnRlc3Q8L3NhbWwyOkF0dHJpYnV0ZVZhbHVlPjwvc2FtbDI6QXR0cmlidXRlPjxzYW1sMj
pBdHRyaWJ1dGUgTmFtZT0iQ29tcGFueUlEIj48c2FtbDI6QXR0cmlidXRlVmFsdWU+RlIyMDA4MTIxMjA5MjkwMDwvc2FtbDI6QXR0cmlidXRlVmFsdWU+PC9zYW1sMjpBdHRyaWJ1dGU+PC9zYW1sM
jpBdHRyaWJ1dGVTdGF0ZW1lbnQ+PC9zYW1sMjpBc3NlcnRpb24+PFNpZ25hdHVyZSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CjxTaWduZWRJbmZvPgogIDxDYW5
vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvVFIvMjAwMS9SRUMteG1sLWMxNG4tMjAwMTAzMTUiLz4KICA8U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0ia
HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8+CiAgPFJlZmVyZW5jZSBVUkk9IiMxMjM0Ij4KICAgIDxUcmFuc2Zvcm1zPgogICAgICA8VHJhbnNmb3JtIEFsZ29yaXRobT0ia
HR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz4KICAgICAgPFRyYW5zZm9ybSBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkV
DLXhtbC1jMTRuLTIwMDEwMzE1Ii8+CiAgICA8L1RyYW5zZm9ybXM+CiAgICA8RGlnZXN0TWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3NoYTEiLz4KICA
gIDxEaWdlc3RWYWx1ZT5lNDZMcmRBOEdhNFkyeEVjK3BxSS9SejVUdUk9PC9EaWdlc3RWYWx1ZT4KICA8L1JlZmVyZW5jZT4KPC9TaWduZWRJbmZvPgogICAgPFNpZ25hdHVyZVZhbHVlPkhha
XA1UlJpSGRHTW5WaXRNZXNzUXowQnZtMWF5UjA4eHVVd1hFSWZrc3BGT0xmamI3am9ISEVYejQxUC9wZkFhV0NETXdsTU5yaWQ5ZytKY1JKdE0xeHdCTlRwT0ZrblB6Um9zcDBUQ25EMHF4U
UVVVGJiUlBFSFBoTW9JU0RUMU1yNXU1NUZKNDB6TmdzVmhLSXd0NER2TVhJdVlFRUFRMFFuZ3prakFWYz08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5RGF0YT48WDUwOUNlcnRpZ
mljYXRlPk1JSURnRENDQXVtZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRUUZBRENCalRFTE1Ba0dBMVVFQmhNQ1JsSXhEREFLQmdOVkJBZ1RBMGxrWmpFT01Bd0dBMVVFQnhNRlVHRnlh
WE14RERBS0JnTlZCQW9UQTBGRVVERU1NQW9HQTFVRUN4TURTVkJETVJZd0ZBWURWUVFERXcxVVpYTjBJRUZFVUNCVFUwOGdNU3d3S2dZSktvWklodmNOQVFrQkZoMXVhV052YkdGek
xteGhhV2RzWlVCbGRYSnZjR1V1WVdSd0xtTnZiVEFlRncwd09UQTVNak13T1RJeE1ESmFGdzB4T1RBNU1qRXdPVEl4TURKYU1JR05NUXN3Q1FZRFZRUUdFd0pHVWpFTU1Bb0dBMVVFQ0JNR
FNXUm1NUTR3REFZRFZRUUhFd1ZRWVhKcGN6RU1NQW9HQTFVRUNoTURRVVJRTVF3d0NnWURWUVFMRXdOSlVFTXhGakFVQmdOVkJBTVREVlJsYzNRZ1FVUlFJRk5UVHlBeExEQXFCZ2t
xaGtpRzl3MEJDUUVXSFc1cFkyOXNZWE11YkdGcFoyeGxRR1YxY205d1pTNWhaSEF1WTI5dE1JR2ZNQTBHQ1NxR1NJYjNEUUVCQVFVQUE0R05BRENCaVFLQmdRREJmU0VnbUsyR2l3MGF6a
ms4UGhTK1Q2NHJvS3hHV0tIREs4RDhTT2tOaXhqM3VDdmlKTURvWXFwcThMQVN6Zi8yU3diQXRsQm9KM1dxd0k1NzZsbEhjUUVrUlNVUEduZTVyTDFHb2ZDc0xpcGxBN3g2NlNOQzdvUmY3ajFV
cEdreWx3MjRiNmJjZ1ZZNFlYK0ZrRXBIcG5vS0dsMHlUMzkzejJBdlBMTkFxUUlEQVFBQm80SHRNSUhxTUIwR0ExVWREZ1FXQkJTWGcyL2FJd3VZNzROMncrdGRnZ2RlNUUrWldUQ0J1Z1lEVlIwak
JJR3lNSUd2Z0JTWGcyL2FJd3VZNzROMncrdGRnZ2RlNUUrWldhR0JrNlNCa0RDQmpURUxNQWtHQTFVRUJoTUNSbEl4RERBS0JnTlZCQWdUQTBsa1pqRU9NQXdHQTFVRUJ4TUZVR0Z5YVhNe
EREQUtCZ05WQkFvVEEwRkVVREVNTUFvR0ExVUVDeE1EU1ZCRE1SWXdGQVlEVlFRREV3MVVaWE4wSUVGRVVDQlRVMDhnTVN3d0tnWUpLb1pJaHZjTkFRa0JGaDF1YVdOdmJHRnpMbXho
YVdkc1pVQmxkWEp2Y0dVdVlXUndMbU52YllJQkFEQU1CZ05WSFJNRUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkJBVUFBNEdCQUFkRTRWSnp2MUNZejJjUDNCQitsQUZWNmkyWTRDcW9Q
WVA2SE9HNkpHWGx6SVYzL2NMZitDVHBRa0h1UG5sRmtIbjV6M3Ixbk1kRlVrUFoyMGZ1T3ZqSW9jemQrOE9CRkEvQ3U0Zkg2VzU2ZHc1dEFxR09wbW11ZmhVODFKdktmYkVwc1pxOW9SSFJuR
mV6MlZnOU1NRVA4c1BWeHY5TUY4ZDF0dlFPWUEvdjwvWDUwOUNlcnRpZmljYXRlPjxYNTA5SXNzdWVyU2VyaWFsPjxYNTA5SXNzdWVyTmFtZT5PVT1JUEMsIE89QURQLCBMPVBhcmlzLCBT
VD1JZGYsIEM9RlI8L1g1MDlJc3N1ZXJOYW1lPjxYNTA5U2VyaWFsTnVtYmVyPjA8L1g1MDlTZXJpYWxOdW1iZXI+PC9YNTA5SXNzdWVyU2VyaWFsPjwvWDUwOURhdGE+PC9LZXlJbmZvPjwvU2ln
bmF0dXJlPjwvc2FtbHA6UmVzcG9uc2U+" />
</form>
</body>
</html>
Figure 6 POST sample
10
The SAML 2.0 Response expected by the ADP Federation Service Gateway must include some mandatory SAML
attributes. Those mandatory attributes are highlighted in the following examples.
<samlp2:Response Destination="https://sso.dev.ehc.adp.com/samlsp" ID="ResponseId_cbf85a04b9b6f12187005c07ac991125" IssueInstant="2017-

02-28T10:35:15.875Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp2="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://sso.dev.ehc.adp.com/_idpprovider</saml2:Issuer>
<samlp2:Status>
<samlp2:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp2:Status>
<saml2:Assertion ID="SamlAssertion-756e03aa504b072b3692a0a50582ab9a" IssueInstant="2017-02-28T10:35:15.874Z" Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="ADP-
IPC">nlaigle</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData NotOnOrAfter="2017-02-28T10:45:15.875Z"
Recipient="https://sso.dev.ehc.adp.com/samlsp"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2017-02-28T10:33:15.875Z" NotOnOrAfter="2017-02-28T10:45:15.875Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://sso.dev.ehc.adp.com/samlsp</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="CompanyID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue>FR20081212092900</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="ApplicationID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue>test</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
<saml2:AuthnStatement AuthnInstant="2017-02-28T10:35:15.874Z">
<saml2:SubjectLocality Address="11.129.224.1"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</samlp2:Response>
Figure 7 Unsigned SAML Response
ADP Federation Service Gateway is using XPATH expressions in order to parse the received “SAML Response”.
Mandatory XML elements (except those requested by the SAML 2.0 standard) are:
• <SAMLResponse>
• <SAMLResponse><Status value= « Success »>
• <SAMLResponse><Assertion>
• <SAMLResponse><Assertion><Issuer>
• <SAMLResponse><Assertion><Subject><NameID>
• <SAMLResponse><Assertion><Conditions>
• <SAMLResponse><Assertion><AttributeStatement><Attribute Name= « ApplicationID »><Attribute Value>
• <SAMLResponse><Assertion><AttributeStatement><Attribute Name= « CompanyID »><Attribute Value>
All those elements must then be included in ADP customer generated “SAML Response” and elements names are
case sensitive.
In order to ensure data exchange security and privacy between ADP customers and the Federation Service Gateway,
the only supported transport protocol is HTTPS and SAML assertion must be signed with the ADP customer X.509 V3
certificate.
If a request is made to the ADP Federation Service Gateway using the HTTP protocol (TCP port 80) an “Unauthorized”
response (HTTP returns code 401) is send to the requester.
11
<samlp2:Response Destination="https://sso.dev.ehc.adp.com/samlsp" ID="ResponseId_cbf85a04b9b6f12187005c07ac991125" IssueInstant="2017-02-28T10:35:15.875Z" Version="2.0"

xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp2="urn:oasis:names:tc:SAML:2.0:protocol">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#ResponseId_cbf85a04b9b6f12187005c07ac991125">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>+Dl2PNglw9JYToM9rKQHDRNw64k=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>C3M8hOgUw32YE0liZ+E4aHOFHTS06RIHEwZULs9C1aV7vorsUypxH3pOBcEIWqwJvBeRkUBYeyNnlSAlqynf4HGORBv67lf/EiCRQmCCS0vjzjDr/j3pOR1MYVDE2NZ7JxZ8
gkPPa+omwOb8V1fjHxnYMsInJgCMOPlY61bweMHzXh/fB5Jim5rqesLhlqv646Z5NOv+6LhcgQjpC3DIF8jjveX/VOwHHngSNsxvoVQoe+e9jzdfTuj6JWIrLKZ0JDBpWgwWEJCuPoI9WAjSCvr3NvKFrvBct
EFjO4xGVew0EDDLDpq02W+RTjCMkBPLazxxEbUL8YqVetZavUGs2w==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIHDzCCBfegAwIBAgIQX6Je/XdffQAMCWIt5q9FgDANBgkqhkiG9w0BAQsFADB3MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xH
zAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxKDAmBgNVBAMTH1N5bWFudGVjIENsYXNzIDMgRVYgU1NMIENBIC0gRzMwHhcNMTUwOTA3MDAwMDAwWhcNMTcwOTA3MjM1OTU5Wj
CCARsxEzARBgsrBgEEAYI3PAIBAxMCVVMxGTAXBgsrBgEEAYI3PAIBAgwIRGVsYXdhcmUxHTAbBgNVBA8TFFByaXZhdGUgT3JnYW5pemF0aW9uMRAwDgYDVQQFEwcwNTY4MzI4MQswCQY
DVQQGEwJVUzEOMAwGA1UEEQwFMDcwNjgxEzARBgNVBAgMCk5ldyBKZXJzZXkxETAPBgNVBAcMCFJvc2VsYW5kMRQwEgYDVQQJDAsxIEFEUCBCbHZkLjEoMCYGA1UECgwfQXV0b21hdGlj
IERhdGEgUHJvY2Vzc2luZywgSW5jLjEVMBMGA1UECwwMQURQIC0gRXVyb3BlMRwwGgYDVQQDDBNzc28uZGV2LmVoYy5hZHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
2BqLDaGkgv1dkZ5TiuVRjbva1XGghCL6wc9xTJQgPM6/nLhZt8wUMDoqoUtc4aC8hfR+QslbTmYoRJoyFVRGutJrlbVxaikNZJAob53Yd0C2TH2NMUaMoUr1VZ01G5yf7N/hVnWY7vY2pWRgpD3Et9UD
Fb2WDzs6p28KcVFN0vJNCI3SNN00jcBhW7s7sxZ3sOcbcsdH92q8VgJumasyhyoxuLmfXq5WBz76bdW3gQEIGsQhgAUZiN1yMQ1OQWvxmzAwS8qglja7+n7Bt+okqkT3q2JUHFliYC6B4+g0Y96l/sVb0
+s4i9KyNa6rrfLbzpHyP+2a3JFhp6e9kpS9twIDAQABo4IC7zCCAuswHgYDVR0RBBcwFYITc3NvLmRldi5laGMuYWRwLmNvbTAJBgNVHRMEAjAAMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwZgYDVR0gBF8wXTBbBgtghkgBhvhFAQcXBjBMMCMGCCsGAQUFBwIBFhdodHRwczovL2Quc3ltY2IuY29tL2NwczAlBggrBgEFBQcCAjAZGhdodHRwczovL2Q
uc3ltY2IuY29tL3JwYTAfBgNVHSMEGDAWgBQBWavn3ToLWaZkY9bPIAdX1ZHnajArBgNVHR8EJDAiMCCgHqAchhpodHRwOi8vc3Iuc3ltY2IuY29tL3NyLmNybDBXBggrBgEFBQcBAQRLMEkwHwYIK
wYBBQUHMAGGE2h0dHA6Ly9zci5zeW1jZC5jb20wJgYIKwYBBQUHMAKGGmh0dHA6Ly9zci5zeW1jYi5jb20vc3IuY3J0MIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgAdgCkuQmQtBhYFIe7E6LMZ
3AKPDWYBPkb37jjd80OyA3cEAAAAU+n6bV2AAAEAwBHMEUCIQDRvFBolTJS5/ToFmhcHxoIk4qiSznkY+YTLVDl40xwcgIgHwROxaGg0XrqrBBw1ePXPbCDoLoAe8iRC0EqREVvwBgAdgBWFAaaL
9fC7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAU+n6bZ9AAAEAwBHMEUCIEgppVpeGUOTd8ivYwUK/LajyPxL14UDoKbfNzBvMefTAiEAzNjAAsxgNqVFwMugWF+HPWK0OUl1Cq21qUo8TVwnS
MAAdgBo9pj4H2SCvjqM7rkoHUz8cVFdZ5PURNEKZ6y7T0/7xAAAAU+n6bV+AAAEAwBHMEUCICQqZXZ96x+7zLrJQMEooNteOnnCw5RCftdQqXEXFFbUAiEA8o8PwL5sVC8nK//Lye5oGrhUO+cZB1
ZxwTIsb1BPeeYwDQYJKoZIhvcNAQELBQADggEBAJxQ8XvGm13rpQjIWXxxz9+QxW9SX4uaXZd1ZK9Xy6k7AajyCIw1wCJe+CxUHJmdr1Gm0pRxILnC5dbQR3SHWV426I9EXySAgczA/69dqhyzMpZ
zFuW9TUY9+TFLfCD50nfFyjheIWvZZtX/hagpJzQZBblE864qrOJZbXl8/DIxRCJnnWEw7AqHGvfSE1bgHpL/dO/Q10MQ14QQytGWH2hUrl2Q9dSV4ZlWbQBY/QcjMH8Z9lWiokCTxTQrUC9YaoSZ4vDM
2fP75lD7njWPP0ItI0mKjXQYl8GgWaRhOxle14tQJzeHBO993n3yncbI5tZr8fQReo3HD4iskBTW9nI=</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp2:Status>
<samlp2:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp2:Status>
<saml2:Assertion ID="SamlAssertion-756e03aa504b072b3692a0a50582ab9a" IssueInstant="2017-02-28T10:35:15.874Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="ADP-IPC">nlaigle</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData NotOnOrAfter="2017-02-28T10:45:15.875Z" Recipient="https://sso.dev.ehc.adp.com/samlsp"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2017-02-28T10:33:15.875Z" NotOnOrAfter="2017-02-28T10:45:15.875Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://sso.dev.ehc.adp.com/samlsp</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AttributeStatement>
<saml2:Attribute Name="CompanyID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue>FR20081212092900</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="ApplicationID" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml2:AttributeValue>test</saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
<saml2:AuthnStatement AuthnInstant="2017-02-28T10:35:15.874Z">
<saml2:SubjectLocality Address="11.129.224.1"/>
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
</saml2:Assertion>
</samlp2:Response>
Figure 8 Signed SAML Response
12
ADP Federation Service Gateway is using some XPATH expression in order to parse the signature elements sent by
ADP customers.
Mandatory XML elements (except those requested by the SAML 2.0 and XMLdSign standard) are:
• <Signature>
• <Signature><X509Data>
• <Signature><X509Data><X509Certificate>
All those elements must then be included in ADP customer generated “SAML Response” and element names are case
sensitives.
To summarized, generation/consumption of SAML Response involves:
• ADP customer must provide as a Requirement the public key of its X.509 V3 digital certificate.
• ADP provides to its customer the application code corresponding to the “ApplicationID” element value and that match
the ADP customer subscribed application.
• ADP provides to its customer the “CompanyID“ expected element value.
ADP recommends the use of RSA and SHA256 cryptographic algorithms for signing the <Assertion> element.
SAML 2.0 standard recommends use of exclusive canonicalization method.
2.3. End user authentication
Each ADP customer that has subscribed to Federation Service must authenticate its end users. The customer end user
identifier (cID) is transmitted within the SAML assertion (NameID attribute).
ADP customers are responsible for:
• Ensuring end users authentication using all necessary means and especially using authentication schemes relevant
for ADP core business data security.
• Ensuring the uniqueness of its customer end user ID (cID). Saying so, 2 distinct end users of 2 distinct ADP
customers can still have the same cID knowing that ADP will always use cID in the scope of a given ADP customer.
ADP will ensure uniqueness of ADP user ID within a given customer scope.
2.4. ADP federation service URL integration within corporate portal
The unique entry point for ADP federation service is the public internet URL:
https:// sso.ehc.adp.com/samlsp
We also remind that ADP customer end users will also have to access to ADP application public URLs such as:
https://zadig-hr.adp.com.
ADP also recommends that the Federation Service URL is invoked in a dedicated browser window or browser tab.
Indeed, when the end user disconnect (user initiated disconnect or session timeout), the ADP application will attempt to
self-close the browser window or tab. If this was a dedicated browser window or tab, the end user will then have the
focus on the initial corporate portal window.
13
2.5. Web Browser Requirement
For using ADP Federation Service Gateway:

• 128 bits SSL compatible web browser.
• Use of a dedicated browser window / browser tab for the ADP application. This window / tab may be open by
JavaScript code.
• JavaScript and cookie support.
ADP Federation Service Gateway authentication is ensured by a VeriSign/Symantec server certificate:
VeriSign Certificate Authority is natively recognized by the main market web browser as soon as they are
properly maintained with regular security patches and updates.
14
3. TESTING ENVIRONMENT
ADP provides a testing environment to its customer who wishes to validate SAML assertion production and consumption.
This testing environment is available at:
https://sso.dev.ehc.adp.com/samlsp
This URL provides to ADP customer a SAML Response consumption facility as ADP Federation Gateway would do.
When the SAML 2.0 response is successfully consumed by the ADP Federation Gateway testing environment, a
success page is displayed:
Figure 9 ADP IPC: SSO Authentication success
15
Upon a failure, an error page is displayed and some technical indications concerning the encountered error are provided:
Figure 10 ADP IPC: SSO Authentication failed
Testing environment users are invited to report any encountered problem to their ADP project leader.
Before using the testing environment, ADP customers have to check with their ADP project leader the following points:
• Register their X.509 digital certificate public key in ADP Federation Service Testing environment.
• Request for a testing company ID.
• Request for testing user ID for the testing company ID.
• Upon cases, request for mapping corporate user ID with ADP testing user ID.
Two distinct testing levels are available at the test environment level:
• Full test, with customer and end user profile validation. This test level is achieved using the value “test” for the SAML
optional attribute ApplicationID. In addition to the pre-load of the customer SAML signing certificate, this test level
requires that a dedicated customer profile and some dedicated end user profile are defined on ADP test environment
side.
• SAML test level. This test level is achieved using the value “test-migration” for the SAML optional attribute
ApplicationID. This test level only requires that your SAML signing certificate is known (has been uploaded) in the ADP
cert store related to the test environment.
16
4. END USER MANAGEMENT
One of the greatest difficulties to provide identity federation is that each organization application request that end user is
uniquely identified in order to work properly.
This authentication is likely to be different from one organization to the other.
ADP Federation Service therefore proposes a solution to address this identity propagation from one organization to
another.
This solution relies on the management by ADP of a user identity mapping table (UIDMT). This mapping table is
implemented over the ADP security database and offers all availability and security guaranties requested by ADP core
business.
4.1. UIDMT Synchronization
In order to ensure the synchronization of the ADP Security Database with other organization security database, ADP
proposes to its customer the following solution:
4.1.a. ADP Security database synchronization using a dynamic end user registration:
This scenario involves that ADP is maintaining a UIDMT where it stores ADP user IDs and ADP customer corporate user
IDs.
When requesting an ADP application the end user will provide its corporate user ID and ADP will look in the UIDMT for
the corresponding ADP user ID.
The UIDMT is feed by dynamic self-registration process using a dedicated web application (Self Registration).
This overall system is called hereafter Dynamic Database Synchronization and Self Registration.
The end user knows his ADP credentials. That information is sent to the end user by the standard ADP
application deployment use case.
DDSSR is based on 3 main principles:
• ADP customers have internal process to manage corporate UIDs (add, modify, delete) for their end users.
• ADP has internal process to manage ADP UIDs (add, modify, delete).
• UIDs synchronization is ensure by the end user itself through an online ADP application.
ADP provides the technical infrastructure and the online application for the Self Registration service and UIDMT UIDs
storage.
The ADP Self registration online application is localized and will automatically adapt to end user browser language
preferences.
17
4.1.b. Security database synchronization using ADP user management tools

Mapping management can be processed using ADP user management tools (DUMA / UMA) during the hiring process.
4.1.c. Security database synchronization using ADP Application

Depending of the target application, if the Customer UID is already present in ADP database (email, employee number
…), an automatic consolidation can be processed.
4.2. ADP password management
For security reasons an even though the end user will never use it, the ADP password related to the ADP UID is
automatically modified upon Self Registration process completion or batch initialization.
ADP will also regularly modify those passwords in order to comply with its commitment in security matters.
18
5. KEY POINTS FOR SETTING UP FEDERATION WITH ADP
5.1. SAML Scenario
ADP SSO scenario is based on the SAML 2.0 standard « SAML web browser SSO profile – IDP initiated SSO : post
Binding” only .
5.2. SSO Servers Clock Synchronization
Ensure that SSO server clocks are set to correct time, date, and time zone and ideally synchronized with a time server.
5.3. SAML Response Signing
Description: ADP SAML standard implementation requires SAML Response signature for compliance.
Send Signed SAML Responses: Yes - ALWAYS
5.4. X509 cert Exchange
• ADP SSO Customers must provide their signing X509 certificate in PEM format.
• The Complete certificate chain of signing certificate is not required, even for self-managed internal PKI.
5.5. SSO Authentication Mode
Description: SSO Authentication Mode defines the various possibilities an end user can use to authenticate and
access ADP protected applications.
• SSO Authentication Mode Option: SSO only or Mixed SSO
• “Mixed SSO” and “SSO Only” modes are set by ADP, after SSO activation at the customer level.
• SSO Authentication mode scope is the end user level.
• Default SSO authentication mode is “SSO Only”.
19
5.5.a. Mixed SSO:
End user configured with this SSO Authentication mode has the choice to use the ADP application legacy link, ex
: https://www.multidocs.it.adp.com and sign in using his ADP username and password OR using its company SAML
IDP link that will log him in without using any ADP dedicated credentials.
Upon disconnection, the ADP session is ended, and ADP login screen is displayed.
5.5.b. SSO Only:
End user is not able anymore to access his ADP application legacy login page ex: https://www.multidocs.it.adp.com, he
must use its SAML SSO IDP link to be logged on ADP application.
If the end user tries to logon interactively, a diagnostic message is displayed saying: “You are in SSO mode and must
use your Intranet to logon.
After being logged on, using SSO, upon disconnection, the session is ended, and a message is displayed saying: “You
session has ended, use your Intranet to reconnect”.
20
ANNEX
METADATA
QA/Test Environment
Endpoint https://sso.dev.ehc.adp.com/samlsp
<EntityDescriptor ID="ADP-SAMLServiceProvider-Dev-f12c0e86be1e41ac7db8b4cbd100444e" entityID="https://sso.dev.ehc.adp.com/samlsp"

xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAssertionsSigned="true">
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sso.dev.ehc.adp.com/samsp"
index="0" isDefault="true" />
<AttributeConsumingService index="0">
<ServiceName xml:lang="en">ADP ESI Federation DEV</ServiceName>
<RequestedAttribute isRequired="true" Name="CompanyID" />
<RequestedAttribute isRequired="true" Name="ApplicationID" />
</AttributeConsumingService>
</SPSSODescriptor>
<ContactPerson contactType="technical">
<Company>adp</Company>
<GivenName>nicolas</GivenName>
<SurName>laigle</SurName>
<EmailAddress>access.management@adp.com</EmailAddress>
<TelephoneNumber>+33155440167</TelephoneNumber>
</ContactPerson>
</EntityDescriptor>
Production Environment
Endpoint https://sso.ehc.adp.com/samlsp
<EntityDescriptor ID="ADP-SAMLServiceProvider-Prod-f12c0e86be1e41ac7db8b4cbd100444e"
entityID="https://sso.ehc.adp.com/samlsp" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAssertionsSigned="true">
<AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sso.ehc.adp.com/samsp" index="0"
isDefault="true" />
<AttributeConsumingService index="0">
<ServiceName xml:lang="en">ADP ESI Federation PRODUCTION</ServiceName>
<RequestedAttribute isRequired="true" Name="CompanyID" />
<RequestedAttribute isRequired="true" Name="ApplicationID" />
</AttributeConsumingService>
</SPSSODescriptor>
<ContactPerson contactType="technical">
<Company>adp</Company>
<GivenName>nicolas</GivenName>
<SurName>laigle</SurName>
<EmailAddress>access.management@adp.com</EmailAddress>
<TelephoneNumber>+33155440167</TelephoneNumber>
</ContactPerson>
</EntityDescriptor>
21
ADP Security database synchronization during SETUP : UIDMT batch mode management
Within the setup step of a new ADP customer, ADP can provide a batch mode UIDMT initialization use case.
This use case provides ADP and Corporate UIDs synchronization using file exchange formatted as follow:
• Text file (UTF/8) CSV formatted.
• 5 columns : First name, Surname, Email, ID ADP, ID Client
• Columns separator : « ; » (semi column)
Example of file for batch mode:
Nicolas Laigle nicolas.laigle@europe.adp.com nlaigle-xxx nlaigle
This setup mode for UIDMT is only available during the customer setup phase.
Daily updates of the UIDMT are realized using the standard Self registration use case.
22
Self registration example
The Self Registration use case can be split into different step:
Step 1: Authentication on corporate portal :
The end user authenticates on its corporate portal

with its corporate UID and password (authentication
method may vary).
Once logged in, the corporate portal displays a link

to an ADP application.
The end user click on this link…
The corporate portal generates an identity token

(SAML Assertion) and redirect the end user to the
ADP Federation Service Gateway.
23
Step 2: ADP Federation Service Gateway : UIDMT feeding
The ADP Federation Service Gateway consume the

identity token, retrieve the end user corporate UID and
requests the ADP UID and ADP password.
Email address confirmation to end up the Self

Registration step.
If the end user press “Cancel”, all the Self Registration

use case is cancelled.
Confirmation page
24
Step 3: Registration acknowledgment
The end user received and acknowledgement email

from ADP.
This acknowledgement email contains an hypertext link

for validating the Self Registration.
After having clicked on the validation link, a

confirmation window opens in the end user browser.
The Self registration process is completed.
Self Registration
In the standard Self Registration use case:

• The usual workflow including email generation with ADP login and Password remains unchanged.
• The ADP login and password is used only once by ADP customer end user at the first connection. Once the end user
has associated its corporate ID with an ADP ID, this association is stored in ADP security database.
25

ADP Federation Handbook V1 8

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ADP Federation Handbook V1 8

Uploaded by

Copyright:

Available Formats

INTERNATIONAL PRODUCTION CENTER

ADP Federation Handbook

V1.8 ► February 2017

2.1. X.509 V3 Digital certificate – ADP customer authentication 9

4.1. UIDMT Synchronization 17

5. KEY POINTS FOR SETTING UP FEDERATION WITH ADP 19

5.1. SAML Scenario 19

Modifications follow up table

Version Date Author Status Validator Modification details

This will lead to:

Figure 1 ADP federation scope

1.2. Single Sign On principle

1.2.a. System entities

1 – The end user authenticates in its intranet portal.

1.2.b. Authentication / authorization use case : « post » binding profile

Figure 3 Post binding

1.2.c. Access to ADP application

Figure 4 ADP access sequence diagram

2. ADP CUSTOMER REQUIREMENT

2.1. X.509 V3 Digital certificate – ADP customer authentication

2.2. SAML assertion generation

<samlp2:Response Destination="https://sso.dev.ehc.adp.com/samlsp" ID="ResponseId_cbf85a04b9b6f12187005c07ac991125" IssueInstant="2017-

<samlp2:Response Destination="https://sso.dev.ehc.adp.com/samlsp" ID="ResponseId_cbf85a04b9b6f12187005c07ac991125" IssueInstant="2017-02-28T10:35:15.875Z" Version="2.0"

Figure 8 Signed SAML Response

To summarized, generation/consumption of SAML Response involves:

• ADP provides to its customer the “CompanyID“ expected element value.

SAML 2.0 standard recommends use of exclusive canonicalization method.

2.3. End user authentication

ADP customers are responsible for:

2.4. ADP federation service URL integration within corporate portal

2.5. Web Browser Requirement

For using ADP Federation Service Gateway:

ADP Federation Service Gateway authentication is ensured by a VeriSign/Symantec server certificate:

Figure 9 ADP IPC: SSO Authentication success

Figure 10 ADP IPC: SSO Authentication failed

• Request for a testing company ID.

• Request for testing user ID for the testing company ID.

4. END USER MANAGEMENT

This authentication is likely to be different from one organization to the other.

4.1. UIDMT Synchronization

DDSSR is based on 3 main principles:

4.1.b. Security database synchronization using ADP user management tools

4.1.c. Security database synchronization using ADP Application

4.2. ADP password management

5. KEY POINTS FOR SETTING UP FEDERATION WITH ADP

5.1. SAML Scenario

5.2. SSO Servers Clock Synchronization

5.3. SAML Response Signing

5.4. X509 cert Exchange

5.5. SSO Authentication Mode

• SSO Authentication mode scope is the end user level.

• Default SSO authentication mode is “SSO Only”.

5.5.a. Mixed SSO:

5.5.b. SSO Only:

<EntityDescriptor ID="ADP-SAMLServiceProvider-Dev-f12c0e86be1e41ac7db8b4cbd100444e" entityID="https://sso.dev.ehc.adp.com/samlsp"

• Text file (UTF/8) CSV formatted.

• 5 columns : First name, Surname, Email, ID ADP, ID Client

• Columns separator : « ; » (semi column)

Example of file for batch mode:

Nicolas Laigle nicolas.laigle@europe.adp.com nlaigle-xxx nlaigle

Self registration example

Step 1: Authentication on corporate portal :

The end user authenticates on its corporate portal

Once logged in, the corporate portal displays a link