single sign on tutorial

1. S S O T E C H N O L O G I E S
&
T H E S I F 3 I N F R AS T R U C T U R E
Addressing the Beast: Single
Sign-On II
© Access 4 Learning (A4L) Community

2. What do we want?
SSO – When using other
Single or Same Sign On
technologies the chosen
standard must be
followed. If you would
like to include an
indicator for the SSO
standard of your choice,
please submit it (along
with justification as to
why it is the appropriate
indicator) so it may be
included in the
specification. Additionally
providing a guidance
document for others on
how to consistent use
the chosen SSO solution
is desirable.
© Access 4 Learning (A4L) Community

3. What do we have?
© Access 4 Learning (A4L) Community
 OAuth 2.0
 Password Grant
 Bearer Token

4. How does it work?
© Access 4 Learning (A4L) Community
 POST: Credentials to one URL.
 200: Authentication Token +
 GET*: Request to another URL with Bearer Token
 200: Data
• Other operations supported.

5. OAuth 2.0
Service
Provider
User with
Device
Identity
Provider
Request
Unauthenticated
Request /w Token
Data

6. How does it work?
© Access 4 Learning (A4L) Community
 Token creation.
 Password Grant
 Username
 Password
 Client
 Secret

7. © Access 4 Learning (A4L) Community

8. How does it work?
© Access 4 Learning (A4L) Community
 We get a JSON payload in response.
 It must include the token and type.
 We must keep the token to reuse for access.
 The type must be bearer.
Note: When leveraging OAuth 2.0 the proper capitalization
when providing a token in either an Authorization header or
authenticationMethod query parameter is “Bearer.” However
when returned as the token_type (by the OAuth 2.0 server) it
MUST be treated as case insensitive and will often be all
lower case.

9. © Access 4 Learning (A4L) Community

10. How does it work?
© Access 4 Learning (A4L) Community
 Now the token is used verbatim.
 It can go in one of two places.
 The Authorization header with a Bearer qualifier (preferred).
 The access_token query parameter (more likely to be logged).
Note: Production applications should be prepared for token
expiration.

11. © Access 4 Learning (A4L) Community

12. How does it work?
© Access 4 Learning (A4L) Community
 Now we get the Response.
 Hopefully data.
 Could be an error*.
* Cannot count on getting a SIF 3 error in the HTTP
body.

13. How does it work?
© Access 4 Learning (A4L) Community

14. © Access 4 Learning (A4L) Community

15. What is missing?
© Access 4 Learning (A4L) Community
 Mechanism to confirm supplied token.
 It is not A4L, it is missing from OAuth 2.0.

16. Trusted 3rd Party
Service
Provider
User with
Device
Identity
Provider
Request
Unauthenticated
Request /w Token
Data

17. How will we fill the gap?
© Access 4 Learning (A4L) Community
 Open ID Connect
 http://openid.net/connect/
 Google Does It
 https://developers.google.com/identity/protocols/OpenIDConn
ect

18. What is next?
© Access 4 Learning (A4L) Community
 SAML (Shibboleth)
 OpenID Connect (OAuth+)
 SSL/TLS (Certificate Authority)
 Kerberos (Active Directory)

19. How can you help?
© Access 4 Learning (A4L) Community
 Help lead the Identity Management Group.
 Share your expertise within the group.
 Contribute your preferences and priorities.

20. Contact Information:
 John W. Lovell
 jlovell@a4l.org