Difference between revisions of "SSO (Single Sign On)"

Latest revision as of 16:35, 21 January 2019

What is SSO ?[edit]

Single sign-on (SSO) is a property of access control of multiple related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. This is typically accomplished using the Lightweight Directory Access Protocol (LDAP) and stored LDAP databases on servers. In our context, purpose is to bypass the Accelerate login page for internal users (buyers) by providing automatically credential information as long as the user is authenticated in its professional network For supplier contacts, which are not customer internal employees (therefore not in the directory database), the login page should remain the standard one So SSO implementation has to consider both situations

What are the benefits of SSO ?[edit]

Benefits of using single sign-on include:
-Reducing password fatigue from different user name and password combinations
-Reducing time spent re-entering passwords for the same identity
-Reducing IT costs due to lower number of IT help desk calls about passwords

How often is SSO setup at SynerTrade ?[edit]

17 clients (/210) uses SSO so far (Q3 2014)

Does Accelerate or ST6 have a standard SSO feature ?[edit]

We implemented very specific SSOs so far, as well as more generic/standardized ones. So far implemented SAMLv2 and Kerberos SSO can be considered as our 2 standards (for ST6 as well as Accelerate). This means if the customer can fit one of these technologies, only configuration is needed, not implementation.

What is the cost of implementing a specific SSO ?[edit]

History proves SSO implementations (IT workload only) vary from 5 to 10 mandays To which needs to be added consultant workload of specifications, workshops and acceptance Total project cost is therefore between 10 to 20 days

What are the key success factors ?[edit]

SSO cannot be tested by the PS consultant, simply because he does not exist on any directory + he’s not on customer’s site most of the time (office or other customer’s sites) Therefore it is extremely important to book regular acceptance sessions with:
-PS technical Consultant
-IT developer from SynerTrade
-IT admin from SynerTrade (Paul’s team)
-IT developer from customer side
-IT admin from customer side
Experience tells us that always last minute adjustments are necessary on IT settings (IPs, firewalls, sometimes even coding) therefore all participants are mandatory

How does SSO work ?[edit]

There is no unique standard way of implementing SSO. Multiple standards exist, along with multiple technologies. Yet the global concept is quite always the same:
First of all, the user HAS to exist in Accelerate database, as an internal user. This can be achieved by 3 ways:
- Users are created from a LDAP import interface (to avoid maintenance efforts if employee turnover or modification is important)
- Users are created manually in Accelerate as usual (in that case in some way one field should allow to match with the external identity provider (email, login…)
- Users are automatically created, if not exist, at first login attempt : this is somehow hazardous but some customers use it when a large population should reach tender “definition of demand” phase, without knowing in advance who to invite/create.
SynerTrade’s recommendation goes for options 1 or 2

Provided one user exists in Accelerate, the login use case can be:
• User calls a specific Accelerate URL (manually or by clicking a link from an intranet/portal)
• That page redirects to an identity provider, which returns encrypted credentials of that user
• A specific accelerate program decrypts and matches credentials with interface user database
• If exist the user is automatically logged in to SynerSpace
• Else he reaches the standard login page

Sometimes the initial call to Accelerate page already contains all necessary credentials
Sometimes credentials are encrypted and stored on a cookie
See all possible existing implementation in Jira : http://jira.SynerTrade.com/browse/RVI-71316

Some words about Directory import via LDAP[edit]

IMPORTANT : in no case Accelerate is the master database for users : directory is always the master base. The customer directory contains all information about an employee:
• Name
• Address
• Phone/Fax/Email
• Credentials
• Department/Cost centers
• Organisational scope

Groups exist in the directory to gather users from a same population (by department, or by privilegies).
Information transferred by the directory to create users in accelerate can vary from the minimum necessary fields (first and last name, email address) to much more information such as:
• Organizational scope (ie AOs in Accelerate : BU, OU, legal entities)
• Roles (ex : legal department => contract buyer)

Anyway, and because it is important NOT to import in Accelerate all possible company employee, it is mandatory that purchasing employees can be isolated easily by filtering by directory groups. If this can’t be achieved, an LDAP import is not recommended

What about deeplinks ?[edit]

Deep link allow entering the application and reaching a specific page, directly from one email hyperlink. Typical use case is:
• User clicks on email link
• Browser opens the accelerate login page
• User enters credentials
• System redirects (provided login info is correct) directly to the desired page
When the customer benefits from a SSO, the internal user expects having NOT to re-authenticate when using deeplinks, meaning the deeplinks should somehow involve the possible SSO specific programs. This must definitely be checked during implementation.

Topics to be discussed with customer during SSO workshop[edit]

Is a LDAP import necessary? If yes :
• what is the directory technology (MS Active Directory, other ?)
• which scope of user information:
o only name, email and credentials ?
o or also authorization objects and roles (ex : if user belongs to french legal department then he gets Contract Buyer role + “france” business unit)
• Do specific groups exist to isolate the necessary users to be created ?

Do you have mobile employees or homeworkers ?
If the SSO is involving the requester IP to be in a list of whitelisted IPs for SSO, homeworkers or mobile employees will not be able to access the application with SSO unless they have VPN Access

Can the customer fit with SAMLv2 or Kerberos SSO technologies ?
Because in this case no implementation should be required on SynerTrade’s side

Else what technology is used for identity providing ?
Can be house-made,Integrated Windows Authentication, …

What deliverables does PIM/IT expect ?[edit]

For SSO it is not necessary to write a Discovery Paper, neither create a IE ticket. On the other hand, the Statement of Needs (SoN) is necessary and should be attached to a XLR ticket