SSO Deployment Options for On-premise Adobe Connect Installations
This article is intended as a supplement to the Helpx tech-notes on the topic of Single sign-on, SSO with Adobe Connect 10.x: Enabling single sign-on in Adobe Connect
After your Adobe Connect account is configured and enabled as a service provider on the IDP server: Log onto your Adobe Connect Central domain on-premise as an admin in any browser and paste the following API into the browser URL while logged in as an admin. Note that if you just hit this as an external URL or paste it into a browser that is not already logged into Adobe Connect Central with admin rights, it will fail to execute: https://youradobeconnectonpremisedomain/api/xml?action=acl-field-update&field-id=account-level-sso-enable&value=true&acl-id=7 This API will enable the SSO feature and allow the drop down and import options in Adobe Connect Central under Administration>Users and Groups>SSO Settings.
On support for multiple SSO domains with a Single IDP server: Currently we do not officially support multiple domain name with single IDP server on our hosted platform, but there is a way to manually edit a workaround into on-premise servers; change the login.xsl file to decide which domain to redirect or not. (editing the redirect login in login.xsl file) in \appserv\apps\system\login.xsl. This makes it possible to work with one IDP allowing multiple domain users being authenticated; note that it must be the same IDP.
For example: If you have an ADFS IDP server and there are two types of domain users: @adfs.com and @adfs1.com, with the current default OOTB configuration, only one set of users can be authenticated, (the other one will be ignored). To authenticate the other set of users, we can edit the redirectToIDPserver function in login.xsl to allow for the authentication of @adfs.com and @adfs1.com domain users.
You would setup the normal IDP configuration but then you edit the redirectToIDPServer function in login.xsl file: \appserv\apps\system\login.xsl See the bold text below; add the additional domain names separated with commas; in this example see the added: ‘adobe1.com’ and ‘adobe2.com’ domain value.
function redirectToIDPServer(){
<xsl:variable name=”unescapedoktadomain” select = “/results/params/param[@name=’oktadomain’]” />
var oktadomain = “<xsl:value-of select=”xxt:escapeJavaScript(string($unescapedoktadomain))”/>”;
<xsl:variable name=”unescapedoktaloginurl” select = “/results/params/param[@name=’oktaloginurl’]” />
var oktaloginurl = “<xsl:value-of select=”xxt:escapeJavaScript(string($unescapedoktaloginurl))”/>”;
// insert the domain name in otherDomainName Arrays
var otherDomainName = [oktadomain, ‘adobe1.com’ , ‘adobe2.com’];
var loginName=$(“input[name=login]”).val();
var registerTab = document.getElementById(“registeredTab”);
if(oktadomain){ for(var i =0 ;i < otherDomainName.length ;i++){ if(loginName.indexOf(otherDomainName[i]) !== -1){ if(!registerTab || registerTab.selected){ var relayState='{“action”:”CPS_WORKFLOW”,”redirect”:”‘+window.location.pathname+'”}’; window.location = makeSSOLoginUrl(oktaloginurl, relayState); return false; } } }
}
return true;
}
<SNIP>
Restart the server.
Note: Only the Connect Central page will be served by the other domain values and not Adobe Connect Event pages or the Adobe Connect Mobile application.
On User Attributes for just in time provisioning: User attributes like FirstName, LastName and Email are required in the SAML response for just in time provisioning. Make sure the below attributes are added in OKTA:
- FirstName Value: user.firstName
- LastName Value: user.lastName
- Email Value: user.email
Look for the following error entries in the debug.log file:
[09-26 15:35:30,151] http-80-4 (INFO) SAML authentication request recived for account connect.adobe.com
[09-26 15:35:30,171] http-80-4 (INFO) New User should be created for SSO workflow
[09-26 15:35:30,171] http-80-4 (ERROR) Name Id: jsupport@isupport.com
[09-26 15:35:30,171] http-80-4 (ERROR) Attribute From IDP server {}
[09-26 15:35:30,171] http-80-4 (ERROR) Unable to initilize okta authentication handler null
[09-26 15:35:30,171] http-80-4 (ERROR) Okta autentication failed, <status code=”okta-auth-error” subcode=”user-not-found”/>
[09-26 15:35:30,171] http-80-4 (INFO) Response status: okta-auth-error/user-not-found
You may check (even though it should be on by default) to see if auto-user provisioning is on; run this Web Services API command on the Adobe Connect Server itself and on the console port, 8510 as shown: http://localhost:8510/api/xml?action=sso-setting-list This will not work in a browser that is not on the server itself and it will not work without localhost:8510. You should see a response similar to this:
<results>
<status code=”ok”/>
<sso-lists>
<sso-list account-id=”7″ on-demand-user-provisioning=”1″>
<login-url>{some value}</login-url>
<entity-id>{some value}</entity-id>
<sso-domain>{some value}</sso-domain>
</sso-list>
</sso-lists>
</results>
If on-demand-user-provisioning is = 1, then it is ON
If on-demand-user-provisioning is = 0, then it is OFF
To change it (if needed for any reason), log in as admin in Adobe Connect Central and then this API in the browser:
To disable: https://{yourConnectURL}/api/xml?action=sso-setting-update&account-id=7&okta-disable=false&on-demand-user-provisioning=false
To enable: https://{yourConnectURL}/api/xml?action=sso-setting-update&account-id=7&okta-disable=false&on-demand-user-provisioning=true
(leave ‘okta-disable’ = false for both and only change the last parameter to true/false).
On Group Enrollment: There isn’t anything automatic within the Adobe Connect SSO solution up to 10.6.1. Group enrollment can be done programmatically with the Web Services API; this would require a customized configuration. You could use the Web Services API to enroll users in groups periodically for example, but there is nothing in the SSO configuration OOTB that would automatically assign users to a group with the IDP integration you are using. If you used LDAP synchronization to build your user-base, you could enroll users using that built-in functionality to synchronize group memberships with your directory, but the users would have to be synchronized from that directory so they would have to be found and managed by the built-in directory service integration in Connect.
On increasing the character length of the domain name entry field beyond the default value of 20: Edit the file saml-setting.xml in deploy\appserv\apps\account path and change the size and max parameter from the default value of 20:
<xsl:call-template name=”input”>
<xsl:with-param name=”name” select=”‘okta-domain-value'”/>
<xsl:with-param name=”title-string” select=”$okta-domain”/>
<xsl:with-param name=”value” select=”$unescapedoktadomain”/>
<xsl:with-param name=”size” select=”20“/>
<xsl:with-param name=”max” select=”20“/>
<xsl:with-param name=”comments” select=”$okta-domain-comments”/>
</xsl:call-template>
You may also use the following API for 10.6.1:
Step 1: While configuring SSO, write any fake placeholder value in the Domain Configuration field such as @test.com
Step 2: trigger the below API in new tab:https://<domain-name>/api/xml?action=sso-setting-update&account-id=<account-id>&okta-disable=false&okta-domain-value=@ssodomainlongname.com
Step 3: Refresh the SSO settings tab.
On lab testing: After installing an Adobe Connect Lab you may be tempted to jump immediately to SSO configuration prior to SSL implementation. Resist this temptation as SSO endpoints must be secure.
See this article for Azure: https://blogs.connectusers.com/connectsupport/configure-sso-in-adobe-connect-with-azure-ad/
See this article for MS ADFS: https://blogs.connectusers.com/connectsupport/configure-sso-in-adobe-connect-with-microsoft-adfs/