What are the pros & cons of using Single Sign-on with LDAP?

sue41
Kilo Explorer

‎09-18-2017 09:08 AM

Hi,

 

I'm brand new to ServiceNow, and have been asked to provide the pros & cons of integrating with  LDAP to provide single sign-on.   There appears to be ample documentation on HOW to implement SSO, but I have not been able to find anything about  when you would want to use SSO and when to avoid it.

Our inititial implementation would cover internal users only, and we would not be using multiple provider SSO.

If SSO is implemented, is it still possible for a user to login to their ServiceNow account  from  the outside, i.e. a personal computer from their home ISP?

Convience for the user while at work seems to be the most obvious  item in the pro column.

What  else should be taken into account when making the determination to use SSO?

Also, if we defer SSO implementation, how difficult is it to implement later?

 

Thank you,

 

Sue

Labels:
0 Helpfuls
  • 2,497 Views
4 REPLIES 4

Aditya Telideva
ServiceNow Employee
ServiceNow Employee

‎09-18-2017 09:26 AM

SSO

With single sign-on (SSO), users are authenticated only once, regardless of how many other applications they attempt to access after the initial login. In general, this is achieved when the SSO Identity Provider (IDP) sends the target applications an assertion that the user has been authenticated and should be trusted by that application.


For example, say a user logs on to Application 1, then decides to access Application 2. Typically, Application 2 would require another username and password for authentication. But in an SSO environment, Application 2 simply determines whether it can authenticate the user based on information the SSO IDP provides. The assertions are typically based on a common protocol like SAML, OpenID Connect, or JWT.


SSO solves two major problems for users:


  1. They don't need to enter authentication information multiple times
  2. …or remember multiple sets of login credentials

It also requires a user repository in order to authenticate a user for the first time. Typical user repositories include Active Directory, LDAP, a custom database, or Stormpath. In turn, these same repositories are often centralized authentication and user management systems.On its own, SSO is a poor solution for sharing user data across applications, as SSO generally expects the application (or "Service Provider" in SSO speak) to maintain its own user management system. More specifically, when an SSO provider sends an authentication assertion to an application, it still needs to create or look up the user in the app's own local repository. Even though the application can trust that the user is authenticated.


LDAP

With centralized authentication, the authentication process is different. Once a user has logged into Application 1, logging into App 2 doesn't feel automatic. Even though the required credentials are identical, the user would still need to enter her authentication information again.Like SSO, Centralized authentication solves two problems, but the problems are different:


  1. Users don't need to remember multiple sets of authentication credentials
  2. The applications they are logging into can share user data.

Typically, centralized authentication solutions completely offload user management from an application. They provide powerful APIs or query languages to connect the user system to one or many applications. Moreover, centralized authentication is often the first step toward a true SSO environment.


SSO vs LDAP?

So, should you use SSO or Centralized Authentication in your application? Of course the answer is: it depends.


  • If you're trying to create a single user repository that all your applications can share, you will want a centralized authentication and user management system.
  • If, on the other hand, you have a variety of applications with their own built-in user data and management, but you want to create a seamless user experience, you'll be best served by SSO (if those apps support it).

Thanks,


Aditya Telidevara


robpickering
ServiceNow Employee
ServiceNow Employee

‎09-18-2017 10:07 AM

Susan,



Just trying to answer your specific questions:


1)   If you have SSO implemented, and the Identity Provider (IdP) is available via the public Internet, then your users will be able to log in from anywhere, on any computer.   However, if you aren't going with an IdP such as Okta, then you'll have to spin up an ADFS (Active Directory Federation Services) SSO IdP and allow it to be reached from the Public Internet to make this work.


2)   Yes, not having to log in to ServiceNow when they've already authenticated to their work computer is the primary convenience.   If they aren't on their work computer, then they'll still have to authenticate to the IdP before being able to login automatically to ServiceNow, so it's a bit of a wash.   However, if you have multiple, authenticated, services that all use the same IdP (or ADFS), then they'll still only have to authenticate once to the IdP, and then can use all of the services, without additional authenticate, even if they aren't on the work network.


3)   The primary consideration for SSO is that you'll have a public IdP you can authenticate to, and that ServiceNow is not the only service to which your users will have to authenticate.   If these are both true, then the value is significant.


4)   If you defer, you can always add it later, it's the same amount of work regardless of when you implement.



Hope that helps.



-Rob


0 Helpfuls