Re: [undertow-dev] CachedAuthenticatedSessionMechanism should return NOT_ATTEMPTED?
On 3/3/2014 8:35 AM, Darran Lofthouse wrote:
I think the problem here is if we return NOT_ATTEMPTED in some
scenarios
where a user was previously authenticated against a web app this could
be quietly lost.
Not following you. If you return NOT_ATTEMPTED, other configured auth
mechanisms will trigger. If you return NOT_AUTHENTICATED, the flow ends.
Returning NOT_AUTHENTICATED on the other hand forces the challenge
phase
again.
No, this does not happen. If NOT_AUTHENTICATED is returned, then no
other Auth mechanisms are allowed to challenge. The request ends.
Is caching against the session really the correct approach for your
mechanism? For a number of mechanisms caching against the session is
actually a bad habit carried over from Tomcat, instead alternative
caching should be employed to optimise subsequent authentication token
validation.
I don't follow you. You're saying storing stuff in Servlet.HttpSession
is bad why? It bleeds into the user space maybe? JBossWeb (Tomcat
too?) has a "session note" feature. Notes are associated with the
HttpSession, but not visible to users. They are only visible at the
Valve layer.
Or are you saying that access tokens should be stored in a cookie?
Maybe its not a big deal performance wise in the overall scheme of
things, but in my case this would involve validating a RSA256 signature
each and every request as well as unmarshalling JSON. I also have
refresh tokens as well which I don't want to be stored in a cookie and
transmitted with each request. Access tokens are short lived and if
somebody gets them, its not as big of a deal as compared to a refresh
token which is much longer lived.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com