Tag: sso

Single-Sign-On between multiple Salesforce Communities with custom domains on same Salesforce org

For a customer I was looking into Single-Sign-On (SSO) between multiple Salesforce Communities using a custom domain for each. Consider a customer with two communities (Community 1 at comm1.example.com and Community 2 at comm2.example.com) – these could be different customer communities, a customer community and a partner community etc. The issue we encountered was that when using custom domains (i.e. comm1.example.com and comm2.example.com) the built in session ID cookie support will not suffice as the cookie will be bound to the exact domain. This means the cookie is not sent along when accessing the second community and hence no SSO.

Now the solution to all this is using SAML with is baked into the Salesforce platform and included in the license. There is a bit more stuff to configure with SAML but once set up you get SSO for non-Salesforce Community properties as well such as a property on Heroku as well.

All in all I think it’s worth the additional configuration.

Before I list what I configured let me say that it may feel a bit convoluted as the Salesforce org is both the Identity Provider (IdP) and the Service Provider (SP) in SAML-speak. Usually Salesforce is either the one or the other but but not both.

Please note: Below I assume a certain level of knowledge about Salesforce Communities around controlling access to communities using Profiles, activating Communities and mapping to custom domains. All is well documented in the documentation but understand you cannot simply do the below steps and be done…

What I ended up configuring was the following:

  1. A community (“SSO”) used for Single-Sign-On and self-service (password reset etc.) where I style and brand the SSO experience at sso.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
  2. A community (“Community 1”) for customers at comm1.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
  3. A community (“Community 2”) for customers at comm2.example.com. The community has a CA signed SSL certificate and a custom domain setup via the Domains setup.
  4. A Customer Community profile with the SSO community as the default community. This profile I use to control access to the communities in Members.
  5. I next configured the Salesforce as an Identity Provider using a self-signed certificate. This will allow the org to act as an IdP in a SAML authentication flow.
  6. Next I created 2 Single-Sign-On configurations (under “Single-Sign-On Settings” in Setup). One for comm1.example.com and one for comm2.example.com with separate, unique, entity IDs and mapping each to the appropriate community as the only login configuration under Workspaces/Administration/Login & Registration. I used “Federation ID” for the SAML Identity Type. Ensure you use the SAML configuration from the SSO community.
  7. Next configure the SSO community to only use “Username & Password” under Workspaces/Administration/Login & Registration. This ensures the customers actually are able to login using their Salesforce credentials.
  8. Under “App Manager” in Setup create a Connected App for each community configuring SAML and using the appropriate entity ID remembering to also set these to use Federation ID.
  9. Allow the community user profile to use the Connected Apps (both of them) and ensure user records have a federation ID set.

The result is that I can access all 3 communities on my custom domains. Accessing sso.example.com simply allows me to logon with username and password and do self-service incl. password reset etc. Accessing either comm1.example.com or comm2.example.com will redirect me to sso.example.com for authentication if not authenticated already. If already authenticated to sso.example.com it will simply bounce me via that and authenticate the user to the community transparently.

YMMV!

Authentication vs. Authorization

When ever I talk to customers and partners about single-sign-on (SSO) and the concepts of “authentication” I’m quite often baffled by the level of misunderstanding, misconception and lack of knowledge about just how “authentication” works. Now the reason I put “authentication” is quotes is that when we talk about authentication it’s really not just authentication we’re talking about. When we talk about confirming the identity of a user and confirming that the user is allowed to access a given resource we actually talk about two related concepts which are always performed – 1) authentication and 2) authorization.

Authentication is the process by which we authenticate the user i.e. find out that the user is authentic and is who he or she claims he or she is. This is most often done using a username and a password but there are numerous ways of doing this. The authentication step is most often followed immediately by authorizing the user to perform a certain task or access a certain resource. A user may be authenticated but not authorized i.e. we know who the user is with certainty but the user is not allowed to perform the operation or access the resource he or she set out to perform or access. A user may also be authorized without being authenticated in which case we allow an non-authenticated user (e.g. Anonymous in IBM Domino) to have certain rights in the system. The latter is the case where an Anonymous user is allowed to open a database, browse a web site etc.

The failure to distinguish between these two steps can lead to a lot of SSO issues and errors not being easily understood and/or debugged. Consider the case where a user signs into System A (i.e. authenticates and the user account authorized to perform the task at hand) and then moves on to System B to access another resource or perform a task which the user is “suddenly” unable to perform. Why? The user was able to work in System A so why not in System B?

This is the time where the person debugging this should stop and think…

Is the reason not because the user isn’t authenticated but because he or she isn’t authorized? Could it be that the user is authenticated both by System A and System B but that System B wasn’t able to authorize the user? Maybe because the username was in another format or the particular username permutation not listed in the ACL or group authorizing the user to work in System B. Knowing about the steps performed can make it a lot easier (or just possible) to diagnose.

Using a good old Notes database with a wide open ACL and a simple page displaying the username of the current user (i.e. using @UserName in a piece of computed text) can make all the difference. It easily shows issues with the user being known by a LDAP username (e.g. cn=Mikkel Flindt Heisterberg,ou=Users,dc=intravision,dc=dk) and not by a Domino distinguished name (CN=Mikkel Flindt Heisterberg/O=IntraVision) or SSO not working due to misconfigured domain names, no shared secrets etc. by the user being known as “Anonymous” because the LtpaToken(2) was never sent to the server due to the cookie rules not being fulfilled. Same goes for Websphere Application Server – a simple WAR based application with a servlet displaying the current username is great for debugging.

Hope it clarifies matters and is helpful to someone.

Watch the names when doing SSO between WAS and Domino

This morning I helped a customer because they couldn’t make the beta of the OnTime Group Calendar for IBM Connections work and it turned out to be a Single-Sign-On issue. For the OnTime widgets to work we require SSO between Websphere Application Server and Domino which is trivial to set up. Simply export the SSO keys from Websphere using the Integrated Solution Console (ISC) and import them into the SSO document in Domino Directory. In Websphere Application Server terms this is called cross-cell SSO and is very easy to set up.

After doing this SSO still didn’t work and right of the bat I suspected the good ol’ “multiple O= identifier” issue. The issue is when you incorrectly configure federated repositories and a username is reported by ISC with an extra organization identifier e.g. I would be “CN=Mikkel Flindt Heisterberg,o=IntraVision,o=IntraVision” and not simply “CN=Mikkel Flindt Heisterberg,o=IntraVision” the latter of course being correct. While WAS (and IBM Connections) will work just fine with that type of configuration is can cause SSO not to work correctly or only work when the user authenticates to Domino first the problem being that the DN that WAS sticks into the LtpaToken isn’t valid in Domino.

Verifying the names is easy using “Users and Group/Manage Users” in the left hand menu in ISC.

After reconfiguring federated repositories and restarting Websphere Application Server SSO functioned and the customer was back to using the OnTime Group Calendar widgets.

Configuring SSO between Lotus Domino and Lotus Connections

This morning I configured single-sign-on (SSO) between Lotus Connections and Lotus Domino and was again surprised by how easy it is. The steps are simple:

  1. Open the WAS server administration interface and go to Security > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration.
  2. Select “Authentication mechanisms and expiration” in the “Authentication” section on the right hand side.
  3. Now in the “Cross-cell single sign-on” section specify a set of passwords and export the keys to a file on the file system.
  4. Move the file to your local file system.
  5. Now follow the guidelines in the Domino Administrator help for importing the keys into Domino LTPA configuration.

You speak SPNEGO? If not get out your dictionary at once since lower TCO is in sight if you do…

So the new abbreviation you have to learn is SPNEGO. SPNEGO is a stadardized protocol for single-sign-on (SSO) between diverse systems. The purpose of the protocol is to provide SSO between the operating system and the services you use whether they be on the web or client applications. Basically it means that the credentials of your Windows logon is automatically used and you are logged transparently into any services that are SPNEGO aware (of cause there are provisions for mapping credentials between systems as well).

So what does this mean for you as a Lotus professional?

An easier life is what it will eventually mean. For now SPNEGO can be configured with Lotus Connections since it runs on Websphere Application Server. In fact there was an article on this just recently on developerWorks (SPNEGO TAI: Using single sign-on from Windows to WebSphere Application Server). In the near future you will start laughing as it will be the SSO protocol for Notes 8.5 and maybe even for the Domino HTTP server as well.

This will mean better ease-of-use for users and it will mean a dramatically lowered TCO for Lotus technology as all Lotus products will be able to use industry standard SSO technologies probably even without additional costly SSO software.

How do you like them apples? 🙂