On 1/30/2014 6:24 AM, Nils Preusker wrote:
Hi,
I looked at the admin console and examined the HTTP requests and
redirects and, as far as I can see, you are using a cookie
(KEYCLOAK_SAAS_COOKIE) to exchange the authentication information (OAuth
token) between the JavaScript client app and the REST services.
Is there a specific reason you chose to use a cookie instead of a bearer
token in an authorization header?
The cookie, if you see, is Http-only. So, the browser app has no access
to the token and can't be hit with Javascript attacks. This is all very
specific to the admin console which assumes that it is not running in a
servlet container and getting a HttpSession.
For servlet apps (and those with a http session), token can be stored in
the HTTP session and the browser app just makes rest invocations that
are validated against the http session.
This of course, doesn't quite work well if the browser needs to make
CORS requests. So, there's also a REST invocation that you can turn on
in the adapter that allows the client to get the token. Or, you can
just use the pure Javascript lib that Stian wrote for pure HTML5 clients.
Also, are you planning to integrate the cookie mechanism as
transparently as bearer tokens (transparently validating by configuring
web.xml, adding user and roles to HttpServletRequest etc.)?
Not sure what you mean by that.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com