Presentation given at ISBG in Larvik, Norway May 2014

1. THETHREE S’ - SINGLE SIGN-ON,
SPNEGO & SAML
Gabriella Davis
gabriella@turtlepartnership.com
The Turtle Partnership

2. WHO AM I?
Gab Davis
Administrator, Problem Solver, Stubborn Fixer of Things
Working with IBM technologies and all the things surrounding
and integrating with those
Based in London, about half the time

3. WHAT ISTHIS PRESENTATION
ABOUT?
We are here to talk about concepts
Once you understand the concepts, their requirements,
limitations and benefits you can make decisions about what you
need
Hopefully we will give you a good overview of a bunch of
confusing acronyms

4. I DO NOTTHINKTHAT MEANS
WHATYOUTHINK IT MEANS…

5. PASSWORD SYNCHRONISATION
You may have the same
password but you’re not the
same person

6. SINGLE SIGN ON
!
HELLO, HAVE YOU MET MY FRIEND?
I can vouch for him completely
!
Is trust transferable?

7. ONE PASSWORD,
ONE LOCATION

8. Authenticating against a single
password in a single place
Sametime
Network
Login
Connections
Mail
Mail
LDAP
Password

9. Synchronising passwords across different
systems
Sametime
LDAP
Connections
LDAP
Traveler
Authentication
Password
Synchronisation
Tool

10. STEPS FOR SINGLE PASSWORD,
SINGLE PLACE
For LDAP compliant applications ensure you use the same LDAP
directory source
For Domino systems, configure Directory Assistance to point to an
LDAP source
ensure you have an attribute in your LDAP directory that contains the user’s distinguished name so
Domino is returned a valid user name
You can then empty out the HTTP Password field for all users
This will work for any Domino application, mail , traveler, Sametime etc
The user can be entirely remote and with no access to LDAP directly and this will still work

11. SPNEGO

12. S imPle
N eGotiation
known as NTLM or Kerberos in Active Directory
GSSAPI
Mechanism

13. SPNEGO EXAMPLE FOR
DOMINO
1
USER LOGS
INTO
WINDOWS
STEPS

14. SPNEGO EXAMPLE FOR
DOMINO
1 2
ACTIVE
DIRECTORY
GENERATES
SPNEGO
TOKEN
STEPS
USER LOGS
INTO
WINDOWS

15. SPNEGO EXAMPLE FOR
DOMINO
1 2 3
ACTIVE
DIRECTORY
GENERATES
SPNEGO
TOKEN
USER TRIES
TO ACCESS
DOMINO
WEBSITE
STEPS
USER LOGS
INTO
WINDOWS

16. SPNEGO EXAMPLE FOR
DOMINO
1 2 3 4
ACTIVE
DIRECTORY
GENERATES
SPNEGO
TOKEN
USER TRIES
TO ACCESS
DOMINO
WEBSITE
BROWSER
SENDS
SPNEGO
TOKEN TO
DOMINO
ALONG WITH
USER NAME
STEPS
USER LOGS
INTO
WINDOWS

17. SPNEGO EXAMPLE FOR
DOMINO
1 2 3 4 5
ACTIVE
DIRECTORY
GENERATES
SPNEGO
TOKEN
USER TRIES
TO ACCESS
DOMINO
WEBSITE
BROWSER
SENDS
SPNEGO
TOKEN TO
DOMINO
ALONG WITH
USER NAME
DOMINO
CONTACTS
ACTIVE
DIRECTORY
TO VALIDATE
TOKEN AND
RETRIEVE THE
USER’S NAME
STEPS
USER LOGS
INTO
WINDOWS

18. DOMINO CREATES A LTPATOKEN FORTHE
VALIDATED USER AND GRANTS ACCESS
Enable Multi Server Single Sign-On To
Extend Access To Other Servers

19. SETTING UP SPNEGO
Create a Domino Web SSO document
Set up a SPN for the Domino server in Active Directory
Domino must run under whatever account you set up for it
Run domspnego
Take the output and give it to your AD administrator to run setspn with
Run setspn -a http://<dominohostname> <accountnamerunningdomino>
Update person documents with AD name appended to FullName (and optional
others like krbPrincipalName and LTPA User Name)

20. WHY NOT SPNEGO
It requires Active Directory
It requires users to login to Active Directory
It requires Microsoft Supported browsers
It requires a Windows client for the users
It requires Domino to be on a Windows platform
at least the first Domino server that’s accessed, the rest can then be reached via Multi Server SSO token generated by Domino
!
It doesn’t work at all if the user is remotely connecting and not logging into Active Directory
It has a very specific use case

21. SAML

22. A ssertion
M arkup
L anguage
SAML is a protocol and process for exchanging
authorisation and authentication data for a user
between services and servers
S ecurity

23. IDP (IDENTITY PROVIDER)
Sp (Service Provider)
Sp (Service Provider)
Sp (Service Provider)

24. NO PASSWORDS…..
TO COMPROMISE
TO EXPIRE
TO INTERCEPT
Once a user has
authenticated with the IdP
they won’t be asked again

25. SAML EXAMPLE
25
1
USER
ATTEMPTS TO
LOG IN TO A
WEBSITE
STEPS

26. SAML EXAMPLE
26
1 2
USER
ATTEMPTS TO
LOG IN TO A
WEBSITE
USER IS
REDIRECTED
TO IDENTITY
PROVIDER
STEPS

27. SAML EXAMPLE
27
1 2 3
USER
ATTEMPTS TO
LOG IN TO A
WEBSITE
USER IS
REDIRECTED
TO IDENTITY
PROVIDER
IDENTITY PROVIDER
REQUESTS
AUTHENTICATION OR
(IF USER IS LOGGED
IN) RETURNS
CREDENTIALS
STEPS

28. SAML EXAMPLE
28
1 2 3 4
USER
ATTEMPTS TO
LOG IN TO A
WEBSITE
USER IS
REDIRECTED
TO IDENTITY
PROVIDER
IDENTITY PROVIDER
REQUESTS
AUTHENTICATION OR
(IF USER IS LOGGED
IN) RETURNS
CREDENTIALS
USER IS
REDIRECTED
BACK TO
ORIGINAL SITE
WITH SAML
ASSERTION
ATTACHED
STEPS

29. SAML EXAMPLE
29
1 2 3 4 5
USER
ATTEMPTS TO
LOG IN TO A
WEBSITE
USER IS
REDIRECTED
TO IDENTITY
PROVIDER
IDENTITY PROVIDER
REQUESTS
AUTHENTICATION OR
(IF USER IS LOGGED
IN) RETURNS
CREDENTIALS
USER IS
REDIRECTED
BACK TO
ORIGINAL SITE
WITH SAML
ASSERTION
ATTACHED
ORIGINAL SITE
USES ITS SAML
SERVICE PROVIDER
TO CONFIRM SAML
ASSERTION AND
GRANT ACCESS
STEPS

30. DEFINITIONS
IdP - Identity Provider (SSO)
ADFS (Active Directory Federation Services in Windows 2008 and Windows
2012)
SAML 2.0 only
can be combined with SPNEGO
Enhances Integrated Windows Authentication (IWA)
TFIM (Tivoli Federated Identity Manager)
SAML 1.1 and 2.0

31. DEFINITIONS
SP - Service Provider
IBM Domino (web federated login)
IBM WebSphere
IBM Notes (requires IDVault) (notes federated login)

32. MORE DEFINITIONS
IdP (Identity Providers) use HTTP or SOAP to communicate to
SP (Service Providers) via XML based assertions
Assertions have three roles
Authentication
Authorisation
Retrieving Attributes

33. AN IDP CAN
SERVICE MANY SERVICE PROVIDERS
A SP can be
connected to several
IdPs
An IdP can
use a variety of authentication
methods including multi
factor

34. SETTING UP SAML
Choose your IdP if you don’t already have one
which fits best in your business
Build the IdP
Configure the SP
!
Sounds easy doesn’t it?
It’s really not easy by any means but it is worth the investment in time

35. WHY NOT SAML
Not everything supports it
Traveler doesn’t
Sametime doesn’t
IDVault is a requirement so IDs that can’t be vaulted can’t be
used
multiple passwords, smartcards etc

36. OAUTH

37. NOT EVERYTHING BELONGSTO
YOU
OAuth is an authentication standard
supported by most major cloud providers

38. THE USER &THE CONSUMER
Let’s say you want Facebook to post
on your Connections Activity Stream.
!
We need OAuth for that..
You are the User
Facebook is the Consumer

39. THE SERVICE PROVIDER & ITS
SECRETS
The consumer (Facebook) wanders over to
the Service Provider (IBM Connections) and
asks for permission to post on the Activity
Stream
The Service Provider issues a Secret to
go with every URL request from the user
which authorises access

40. OAUTH SIMPLIFIED EXAMPLE
40
1
USER ASKS
FACEBOOK (THE
CONSUMER) TO
POST ON THEIR
ACTIVITY
STREAM
STEPS

41. OAUTH SIMPLIFIED EXAMPLE
41
1 2
USER ASKS
FACEBOOK (THE
CONSUMER) TO
POST ON THEIR
ACTIVITY
STREAM
FACEBOOK
GOES TO
CONNECTIONS
(THE SERVICE
PROVIDER) AND
ASKS FOR
PERMISSION TO
POST
STEPS

42. OAUTH SIMPLIFIED EXAMPLE
42
1 2 3
USER ASKS
FACEBOOK (THE
CONSUMER) TO
POST ON THEIR
ACTIVITY
STREAM
FACEBOOK
GOES TO
CONNECTIONS
(THE SERVICE
PROVIDER) AND
ASKS FOR
PERMISSION TO
POST
THE SERVICE
PROVIDER GIVES THE
CONSUMER A SECRET
KEY TO GIVE TO THE
USER AND A URL FOR
THE USER TO CLICK
ON
STEPS

43. OAUTH SIMPLIFIED EXAMPLE
43
1 2 3 4
USER ASKS
FACEBOOK (THE
CONSUMER) TO
POST ON THEIR
ACTIVITY
STREAM
FACEBOOK
GOES TO
CONNECTIONS
(THE SERVICE
PROVIDER) AND
ASKS FOR
PERMISSION TO
POST
THE SERVICE
PROVIDER GIVES THE
CONSUMER A SECRET
KEY TO GIVE TO THE
USER AND A URL FOR
THE USER TO CLICK
ON
THE USER CLICKS
ON THE URL AND
AUTHENTICATES
WITH THE SERVICE
PROVIDER
STEPS

44. OAUTH SIMPLIFIED EXAMPLE
44
1 2 3 4 5
USER ASKS
FACEBOOK (THE
CONSUMER) TO
POST ON THEIR
ACTIVITY
STREAM
FACEBOOK
GOES TO
CONNECTIONS
(THE SERVICE
PROVIDER) AND
ASKS FOR
PERMISSION TO
POST
THE SERVICE
PROVIDER GIVES THE
CONSUMER A SECRET
KEY TO GIVE TO THE
USER AND A URL FOR
THE USER TO CLICK
ON
THE USER CLICKS
ON THE URL AND
AUTHENTICATES
WITH THE SERVICE
PROVIDER
THE SERVICE
PROVIDER ,
SATISFIED THE
SECRET KEY IS
GOOD, WILL NOW
ALLOW THE
CONSUMER
ACCESS TO ITS
SERVICES
STEPS

45. THAT WAS REALLY SIMPLIFIED
There are other steps and other secrets to ensure traffic is not intercepted
once authorisation is granted
There are checks to ensure the Service Provider is who it claims to be
You don’t want to accidentally authorise a phishing site
There are also lots of timeouts on the authorisation
!
Make sure you understand the security of both the Consumer and the Service
Provider as well as what access you are granting the Consumer on your behalf

46. IN SUMMARY
Think about what your problem actually is, there are plenty of technologies to make the user
experience seamless but they become ever more complex to build and maintain
What are your priorities. Single password? No password? No authentication with a particular
service
Many solutions require specific operating systems, software and client versions
Make sure you meet all requirements before building a plan you can’t deliver on
Some things are very easy (Single password, SPNEGO)
Some things are very hard (SAML, OAuth)
There is no one solution, you need to choose the combination that delivers for you

47. HOWTO FIND ME
Twitter, blogs, Instagram, Facebook and more
gabriella@turtlepartnership.com
GabriellaDavis (skype)
http://turtleblog.info
gabturtle on twitter and elsewhere