CAS Leveraging CAS to Protect RESTful Resources and Support Non-Browser Clients David Ohsie, EMC Corporation ([email protected]) John Field, Pivotal ([email protected]) Vijaya Bharadwaj, Pivotal ([email protected])
EMC is a Apereo Commercial Affiliate EMC ships CAS embedded in software (and later) some hardware platforms in order to integrate software The three authors (David, John, Vijaya) work on CAS adoption across EMC products I (David) participate on the CAS user list and the CAS appsec working group
Understand the REST challenges to CAS Understand two very, very simple techniques to meet those challenges If these ideas resonate, incorporate into the CAS protocol and codebase
Statement CAS works nicely when the client is a browser “Problem”: Make CAS work with RESTful clients RESTful client working definition: – An http client that doesn’t grok html/javascript A RESTful client may or may not have a person behind it
CAS Server Protected Service GET https://app.com/ 302 Location: https://cas.com/cas/login?service=https://app.com GET https://cas.com/cas/login?service=https://app.com/ 200 [Content of Login page] Browser POST with username and password Browser gets login form 302 Location: https://app.com/?ticket=ST-12345-10.1.1.8 GET https://app.com/?ticket=ST-12345-10.1.1.8 200 Service Response Set-Cookie: MOD_AUTH_CAS_S=sldkf0fj498 CAS Browser Interaction Danger, Will Robinson! POST https://cas.com/cas/login?service=https://app.com/
about the CAS “REST” interface Client has to know when to authenticate Client has to know where to authenticate Solution: use 401 when you need to authenticate instead of a 302 What about browsers? – Key the behavior off of a header. REST clients send them, while browsers don’t.
CAS Server Protected Service X-EMC-MAC-USE-401: TRUE GET/POST https://app.com/ 401 WWW-Authenticate: X-EMC-CAS realm=”EMC CAS” Location: https://cas.com/cas/v1/tickets POST https://cas.com/cas/v1/tickets Content (form encoded) username=u&password=p POST https://cas.com/cas/v1/tickets/TGT-2-abcdefg Content (form encoded) service=https://app.com/ 200 OK Content (text) ST-3-abcdefg GET https://app.com/?ticket=ST-3-abcdefg 200 Service Response Set-Cookie: MOD_AUTH_CAS_S=sldkf0fj498 CAS REST Interaction 201 Location: https://cas.com/cas/v1/tickets/TGT-2-abcdefg CAS REST Endpoint/ Protocol
are we? Positives: – Clients can install a 401 handler to get the Service ticket – 401 unambiguously indicates that a CAS login is required and where it is required to login Negatives: – CAS REST protocol works, but is non-standard
CAS Server Protected Service X-EMC-CAS-V2: TRUE POST https://app.com/ 401 WWW-Authenticate: X-EMC-CAS-V2 realm=”EMC CAS” Location: https://cas.com/cas/login?service=https://app.com&casAction=login GET https://cas.com/cas/login?service=https://app.com&casAction=login 302 Location: https://app.com/?ticket=ST-12345-10.1.1.8&casAction=login GET https://app.com/?ticket=ST-12345-10.1.1.8&casAction=login 204 Set-Cookie: MOD_AUTH_CAS_S=sldkf0fj498 CAS REST V2 Interaction 401 WWW-Authenticate: Basic realm="CAS" GET https://cas.com/cas/login?service=https://app.com&casAction=login Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Now that the user is Authenticated the POST can be repeated
are we? Positives: – Clients can install a 401 handler to get the Service ticket – Actual authentication done via Basic Auth or other standard authentication method – 401 handler is very simple Negatives: – Still requires a special 401 X-EMC-CAS-V2 handler
CAS Server Protected Service X-EMC-CAS-V2: TRUE GET https://app.com/ 302 Location: https://cas.com/cas/login?service=https://app.com GET https://cas.com/cas/login?service=https://app.com 302 Location: https://app.com/?ticket=ST-12345 GET https://app.com/?ticket=ST-12345 200 Set-Cookie: MOD_AUTH_CAS_S=sldkf0fj498 CAS REST V2 Interaction 401 WWW-Authenticate: Basic realm="CAS" GET https://cas.com/cas/login?service=https://app.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Objections Doesn’t CAS have a REST protocol already? – Yes, but it implies that the client knows when and where to use it. – It contains sensitive info in the URI REST clients are programmatic. Why do you need SSO? – Not all REST clients are programmatic – Those that are can still benefit from an IdP and a unified authentication experience
we did it Small change in CAS client to turn 302 into 401 based on incoming header Small addition CAS to the webflow to present 401 basic auth We also have simple a simple 401 handler for the apache httpclient and also a C# version for use with the protocol
Turn login form into 401 basic auth handler to eliminate HTML Turn 302 into 401 to tell the client when authentication is required and where to authenticate That really all it is!
Steps Plan to have code up on github once approved – CAS + mod_auth_cas + java cas client Gauge interest in having this be part of the CAS protocol Eventually pull requests to CAS and mod_auth_cas
davidohsie
meihei3
ma3tk
nagix
emiki
k5k
hhiroshell
freee
yutakikai
inesmontani
07jp27
ohbarye
visional_engineering_and_design
kastner
zakiyama
lynnandtonic
maltzj
malarkey
sonatard
bryan
kneath
chrislema
danielanewman
reverentgeek
chriscoyier
