[undertow-dev] CachedAuthenticatedSessionMechanism should return NOT_ATTEMPTED?

[Bill Burke]

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