Single Sign-On (SSO) Using SAML

Size: px

Start display at page:

Download "Single Sign-On (SSO) Using SAML"

Peregrine Bryant
5 years ago
Views:

1 Single Sign-On (SSO) Using SAML V.2.4 AS OF Visit the SAML SSO Integration section in SCU for additional information

2 OVERVIEW ServiceChannel offers a full-featured single sign-on (SSO) system to improve the security of your team s access to ServiceChannel while making it easier for them to gain access. Our SSO system allows your users to sign in to your system once and then access ServiceChannel as the correct user account with correct permissions without the need to log in again. ServiceChannel supports SAML SSO an enterprise solution for single sign-on supported by all major 3 rd party vendors and tools such as ADFS, SiteMinder, Okta, Ping One/Federate/Identity. In general, SAML SSO is a system level integration where parameters are discussed ahead of time and are passed through an assertion. The assertion can be encrypted and signed, and ServiceChannel will validate the assertion and log in the user to the appropriate application. New users can be created on the fly if the required fields are available in the assertion. ServiceChannel supports Identity Provider Initiated SAML SSO. We do not currently support Service Provider Initiated SAML SSO. This document describes all the details required to complete this integration. For more details on the SAML, see Security Assertion Markup Language in Wikipedia. 2

3 SAML SSO CONCEPTS Step 1. A user authenticates with (logs in to) Identity Provider system (ADFS, SiteMinder, PingFederate, etc). Step 2. The Identity Provider system sends SAML Assertion to Service Provider system (ServiceChannel). Step 3. The Service Provider system (ServiceChannel) validates data provided in SAML Assertion, activates a logged in session, and provides user access to the logged in session with their user s access permissions. 3

4 USER FEED CONCEPTS Note: The User Feed is not required for SAML SSO, but we recommend it as a best practice. There are several options to create user accounts in ServiceChannel: Manually via UI Using User Feed templates (this option is recommended) Using SAML SSO with Just-in-Time Provisioning Regardless the way selected to create user accounts, we highly recommend to use an address as a user identifier in ServiceChannel instead of a username (e.g. JohnDoe@yourcompany.com instead of JohnDoe) to ensure uniqueness of your user identifiers. The following data is provided in a User Feed Template: Subscriber ID Username address Userid Password (should be empty if you are going to limit a user to SSO logins only) Locations/districts/regions this user should have an access to Role NTE, proposal approval and invoice approval limits status (active/inactive) A User Feed Template can be uploaded into ServiceChannel once during initial setup or on a regular basis. Your ServiceChannel SSO Implementation manager will supply a copy of the User Feed template. We recommend automating the process nightly by having an application on your system create a list of all your users that will need access to ServiceChannel in the standard User Feed template format and upload the file to the ServiceChannel servers for processing. 4

5 SAML SSO IMPLEMENTATION ROADMAP Items to Clarify Before Implementation Is SAML going to be used for authentication only? Should users be created/managed through SAML assertions or User Feed? Do you want users to be redirected to some specific page after logging off from ServiceChannel portal? Note: We recommend authentication only SAML SSO with a User Feed as the fastest solution to deploy. Implementation Steps In general, the following steps should be performed to setup SAML SSO: 1. The CLIENT configures the connection to ServiceChannel testing environment. 2. The CLIENT provides the Issuer and certificate (optional) to ServiceChannel. 3. ServiceChannel configures connection in ServiceChannel testing environment. 4. ServiceChannel provides notice to the CLIENT team that the connection is ready for testing. 5. The CLIENT tests the connection with 2 to 3 users to confirm that the access is granted and the person is logged in as correct user. 6. The CLIENT alerts ServiceChannel that the connection is working well and can be deployed into production. 7. The CLIENT selects the day and time when the connection can be deployed into production. 8. ServiceChannel team deploys the connection configuration into the production environment on the selected day and time. Data Required to Configure SAML SSO Connections On the CLIENT side ServiceChannel Certificate (see Appendix A) and endpoints: Production Testing On ServiceChannel side CLIENT certificate and Issuer value from SAML assertions. 5

6 DATA TO BE PROVIDED IN SAML ASSERTIONS ServiceChannel will expect the following information passed in assertions: Field Required Field explanation NameID Required User ID in SC. Should be in the Subject section of SAML assertion. Name Optional Username. Optional User s address. Role Optional User Role as defined in uploaded User Role template. Location Optional Org Unit for the user Location/Store ID, comma-separated list. The user will have an access to all locations if this field is not provided. Region Optional Org Unit for the user Region, comma-separated list. The user will have an access to all regions if this field is not provided. District Optional Org Unit for the user District, comma-separated list. The user will have an access to all districts if this field is not provided. NTELimit Optional NTE limit value. The current value in SC will remain unchanged if this field is not provided. ProposalApprovalLimit Optional Proposal approval limit value. The current value in SC will remain unchanged if this field is not provided. InvoiceApprovalLimit Optional Invoice approval limit. The current value in SC will remain unchanged if this field is not provided. Currency Optional Currency for limits mentioned above. "USD" will be used if this field is not provided. Note: Only the NameID value is required for authentication-only SAML SSO. 6

7 APPENDIX A. SERVICECHANNEL CERTIFICATE Here is the ServiceChannel certificate used with SAML SSO in the CRT format BEGIN CERTIFICATE----- MIIG5DCCBcygAwIBAgIQKZhilpvHXfx2onKlnJ+XMTANBgkqhkiG9w0BAQsFADCB kdelmakga1uebhmcr0ixgzazbgnvbagtekdyzwf0zxigtwfuy2hlc3rlcjeqma4g A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxNjA0BgNV BAMTLUNPTU9ETyBSU0EgRG9tYWluIFZhbGlkYXRpb24gU2VjdXJlIFNlcnZlciBD QTAeFw0xODA3MDUwMDAwMDBaFw0yMDA3MDQyMzU5NTlaMGIxITAfBgNVBAsTGERv bwfpbibdb250cm9sifzhbglkyxrlzdeembwga1uecxmvrxnzzw50awfsu1nmifdp bgrjyxjkmr0wgwydvqqddbqqlnnlcnzpy2vjagfubmvslmnvbtccasiwdqyjkozi hvcnaqebbqadggepadccaqocggebamvoevoaze3xht3bjy92shlssy4bnbi1z462 u/ubhdddbdk62efjwnvsphus7xv2gkf2czfpgxt6ll7ztg9nk3ctw1tewbw1wpvl YGMh4V+CyDnO9i/iDCz4F/IwHj2mFMgJ5V60BJP83Y5p5hQOwZPwX1CZEHkDicZ2 QJ8ZZBo9GjPfLPQC5VngVSgEg+63RZ/QwTSrs8shMTUEnZGrevH2i3CKkNIu51fW VX66Hv6egqzf8D6c7xECGaBJNGTXDbr5dGDZjoOa5orxbIs3LbytjrBSqCwiD92s 0uqw1VunRSqN5k/14SustJ/3a3FByZe2jshqqIUctNx2qDSzJksCAwEAAaOCA2Uw ggnhmb8ga1udiwqymbaafjcvajquwgvykoosvnpfq7q6knrnmb0ga1uddgqwbbtx tmy/idgtmvuxnmdhfbe/tdcxzdaobgnvhq8baf8ebamcbaawdaydvr0taqh/baiw ADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwTwYDVR0gBEgwRjA6Bgsr BgEEAbIxAQICBzArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8u Y29tL0NQUzAIBgZngQwBAgEwVAYDVR0fBE0wSzBJoEegRYZDaHR0cDovL2NybC5j b21vzg9jys5jb20vq09nt0rpulnbrg9tywluvmfsawrhdglvblnly3vyzvnlcnzl cknblmnybdcbhqyikwybbquhaqeeetb3me8gccsgaqufbzachknodhrwoi8vy3j0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FEb21haW5WYWxpZGF0aW9uU2VjdXJlU2Vy dmvyq0euy3j0mcqgccsgaqufbzabhhhodhrwoi8vb2nzcc5jb21vzg9jys5jb20w MwYDVR0RBCwwKoIUKi5zZXJ2aWNlY2hhbm5lbC5jb22CEnNlcnZpY2VjaGFubmVs LmNvbTCCAXwGCisGAQQB1nkCBAIEggFsBIIBaAFmAHYA7ku9t3XOYLrhQmkfq+Ge ZqMPfl+wctiDAMR7iXqo/csAAAFka9y5cAAABAMARzBFAiBckcW0NjKlaXG8ZEMP u71blbalg1qhvblw5sc9f1n3bgihaijfak6z29fkfkgo2+eesmw1mvxoujcw9nww dnwerojhahuaxqdz+d9wwoe1nkh90engmnqrmgyeorishbh1lofxrvgaaafka9y5 tqaabamarjbeaiaqstfxy0iuel7gx2uwvq4dpzcnzvvgdjksmm0mtdfkgaigrfht nrbjjuknpvncr/poyomie93kiyakjcsp18jxpb0adqbvgdtcfpa2aurqc5txpfpw woq4ehalcbcvo6odbxptdaaaawrr3lmvaaaeawbgmeqcihltsb+dvjsmdg9xowb+ BZfAN3BmB97pcy7IzPDaj3sFAiBLTZEiOpY5a1Jw6ikTsEhJeHgAmk2naQXb2yBX TtkQUzANBgkqhkiG9w0BAQsFAAOCAQEAAj9VgpgOnbf1JnJclMSQ26dEp3IFiWwj itnr81dzeaisbrflq97xqqgv3tnlcxhq75wszg7wijvjidudzjps0vvuuuysx2on /6+zqQYZqSWJOHK3QTG7pDFynwmowz9RlaEADKd5+oNSyL4Z7uj1ZXbAsGYn49hR 8BOHrlB/4fitw+VNqtlY5cV8g/dotTp4gGeORhhp0Rg6HMZ3paicUTDQHi5HqKmg ah9igx0dnx0ipf7dhiwmunwxtkeftdffvmbnzrm9hiuxjehuspixl4jeb3zumvch tvot9iawf2h3qiyag2ab2z/r+s9b9muntdf7vgkfhyrmxto2cvyyog== -----END CERTIFICATE

8 APPENDIX B. SAML ASSERTION SAMPLES Authorization-Only SSO Here is a sample of SAML assertion for an authorization-only SSO. Note: Most important fields (Issuer and NameID) are highlighted. <samlp:response ID="_abcd4562-aabb-435f-bcdf " Version="2.0" IssueInstant=" T20:14:25.281Z" Destination=" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol"> <Issuer xmlns="urn:oasis:names:tc:saml:2.0:assertion"> ces/trust</issuer> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:status> <Assertion ID="_abcd4562-aabb-435f-bcdf " IssueInstant=" T20:14:25.281Z" Version="2.0" xmlns="urn:oasis:names:tc:saml:2.0:assertion"> <Issuer> <ds:signature xmlns:ds=" some-values-here </ds:signature> <Subject> <NameID>user_name_here@mydomain.com</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData NotOnOrAfter=" T20:19:25.281Z" Recipient=" /> </SubjectConfirmation> </Subject> <Conditions NotBefore=" T20:14:25.277Z" NotOnOrAfter=" T21:14:25.277Z"> <AudienceRestriction> <Audience> </AudienceRestriction> </Conditions> <AuthnStatement AuthnInstant=" T20:14:25.256Z" SessionIndex="_abcd4562-aabb-435f-bcdf "> <AuthnContext> <AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef > </AuthnContext> </AuthnStatement> </Assertion> 8

9 </samlp:response> Just-In-Time Provisioning SSO Here is a sample of SAML assertion for a Just-In-Time Provisioning only SSO. Important fields are highlighted; Issuer and NameID are required; Region/District/Location and Role are optional and used if you need to restrict user access to some specific locations. <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" ID="_abcd4562-aabb-435f-bcdf " Version="2.0" IssueInstant=" T17:23:50.347Z" Destination=" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"> <saml:issuer> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:status> <saml:assertion ID="_abcd4562-aabb-435f-bcdf " IssueInstant=" T17:23:50.347Z" Version="2.0"> <saml:issuer> <ds:signature xmlns:ds=" some-values-here </ds:signature> <saml:subject> <saml:nameid>user_name_here@mydomain.net</saml:nameid> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata NotOnOrAfter=" T17:28:50.347Z" Recipient=" </saml:subjectconfirmation> </saml:subject> <saml:conditions NotBefore=" T17:23:50.331Z" NotOnOrAfter=" T18:23:50.331Z"> <saml:audiencerestriction> <saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:attributestatement> <saml:attribute Name="Name"> <saml:attributevalue>user_name_here</saml:attributevalue> <saml:attribute Name=" "> <saml:attributevalue>user_name_here@mydomain.net</saml:attributevalue> <saml:attribute Name="Location"> 9

10 <saml:attributevalue>4155</saml:attributevalue> <saml:attribute Name="Region"> <saml:attributevalue>california</saml:attributevalue> <saml:attribute Name="District"> <saml:attributevalue>west</saml:attributevalue> <saml:attribute Name="Role"> <saml:attributevalue>associate</saml:attributevalue> <saml:attribute Name="NTELimit"> <saml:attributevalue>3000</saml:attributevalue> <saml:attribute Name="ProposalApprovalLimit"> <saml:attributevalue>4000</saml:attributevalue> <saml:attribute Name="InvoiceApprovalLimit"> <saml:attributevalue>5000</saml:attributevalue> <saml:attribute Name="Currency"> <saml:attributevalue>cad</saml:attributevalue> </saml:attributestatement> <saml:authnstatement AuthnInstant=" T17:23:26.425Z" SessionIndex="_abcd4562-aabb-435f-bcdf "> <saml:authncontext> <AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef > </saml:authncontext> </saml:authnstatement> </saml:assertion> </samlp:response> 10

Kaltura MediaSpace SAML Integration Guide. Version: 5.0

Kaltura MediaSpace SAML Integration Guide Version: 5.0 Kaltura Business Headquarters 200 Park Avenue South, New York, NY. 10003, USA Tel.: +1 800 871 5224 Copyright 2014 Kaltura Inc. All Rights Reserved.