Embed Size (px)
DESCRIPTION
Today users have too many usernames and passwords. As developers it’s our job to create a useful application not to worry about authorization. Thanks to social media, OpenID and Oauth, the user truly has single sign on. Rather than expecting users to store and remember multiple passwords, application can leverage a user relationship with social media sites they know and trust. In a large enterprise it might be better to keep things in house. That just means we leverage the same technologies internally and not re-invent the wheel. In this talk we’ll show you how.
Citation preview
Solving Single-Sign-On
Introductions
Patrick J. PoerFounder & President
Aaron Stanley KingDirector of Application Development
Ability to authenticate into multiple applications
Uses one login screen across multiple applications
Uses one username / password combination across multiple applications
Logging out of one application, logs out of other applications
Self-Service Account Management
What is Single-Sign-On?
User Management (Identity Management) Central Management of Permissions across
multiple applications (Federated Security) Account Provisioning / User-Registration and
Activation (Access Management)
Identity and Access Management
What Single-Sign-On is NOT?
Storage & Management vs. Communication
Single-Sign-On Protocols
Help Desk Password Reset Requests Cost ~ $32 per call
Regulatory Compliance (HIPAA, Sarbanes-Oxley, etc.) Cost ~ $MM per incident
Federated Authentication Cost ~ TBD
Enhanced Security Cost ~ $MM per incident
“Gartner Says Through 2016, Federated Single Sign-On Will Be the Predominant SSO Technology, Needed by 80 Percent of Enterprises”
IAM / SSO Business Case
How many applications? Underlying User Store (LDAP, SQL, other)? Application Mix:
Browser Applications Desktop Applications Mobile Applications
SSO Protocol Decision Points
HealthCare Company (HIPAA data) 8 Different 3rd party providers 4 different ad hoc SSO pass-through mechanisms Very Poorly Architected LDAP directory 3 Different manual exports and account
synchronizations to 5 different 3rd party providers No central management of user permissions No audit trail for user activity
Example
Data StoreApp
1App
2App
3App
4App
5App
6App
7App
8
Website
CASADLD
S
Encrypted Token
Reference Url
SAML
Form Post
Current SSO Environment
Implement F648’s S3 IAM / SSO Server Integrate all 3rd party providers into one SSO
server Manage all applications permissions and
profile data from a central server Automate account creation and
management Provide self-service account control to super
users Provide audit trail for all user permissions /
activities
Solution
Data Store
App 1
App 2
App 3
App 4
App 5
App 6
App 7
App 8
New SSO Environment
S3Website
Data StoreApp
1App
2App
3App
4App
5App
6App
7App
8
Website
CASADLD
S
Encrypted Token
Reference Url
SAML
Form Post
Current SSO Environment
Aaron Stanley King
Technical Presentation
Protocol Standards
WS-Federation (Web Services Federation) 2006 SOAP extension
WS-Trust 2007 Commonly STS (security token service)
CAS (central authentication service) 2004
OpenID 2005
OAuth2 2006
Token Types
SAML (Security Assertion Markup Language) XML based Uses SOAP
CAS XML based
JWT (JSON Web Token) JavaScript Object Notation based
WS-Federation and WS-Trust
Full blown SOAP web services with WSDL<s:Envelope> <s:Header> <wsa:Action> http://contoso.com/RFP/PlaceBid </wsa:Action> <wsa:To>http://contoso.com/RFPService</wsa:To> <wsa:ReplyTo> <wsa:Address>http://client.fabrikam.com</wsa:Address> </wsa:ReplyTo> <!-- Other headers not shown for brevity --> </s:Header> <s:Body wsu:Id="body"> <!-- application message --> </s:Body></s:Envelope>
CAS
/login credential requestor / acceptor
/logout destroy CAS session (logout)
/validate service ticket validation
/serviceValidate service ticket validation [CAS 2.0]
/proxyValidate service- / proxy ticket validation [CAS 2.0]
/proxy proxy ticket service [CAS 2.0]
OAuth2
/authorize the resource owner logs in, and grants authorization
to the client application. /token
the client application exchanges the authorization code, client ID and client secret, for an access token
/redirect (or sometimes /callback) the client application where the resource owner is
redirected to, after having granted authorization at the authorization endpoint
Demos
