6:39 p.m.
If IdentityManager.verify(Account) returns null, shouldn't
CachedAuthenticatedSessionMechanism return NOT_ATTEMPTED instead of
aborting and returning 403/NOT_AUTHENTICATED? I was expecting that
returning null would start the auth process again.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7:35 a.m.
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.
Returning NOT_AUTHENTICATED on the other hand forces the challenge phase
again.
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.
The places where we do need to cache against the session are for form
based authentication mechanisms as not caching would result in a prompt
to the user on every request, for other mechanisms where we have tokens
coming from the browser we don't cache against the session.
Regards,
Darran Lofthouse.
On 01/03/14 00:39, Bill Burke wrote:
If IdentityManager.verify(Account) returns null, shouldn't
CachedAuthenticatedSessionMechanism return NOT_ATTEMPTED instead of
aborting and returning 403/NOT_AUTHENTICATED? I was expecting that
returning null would start the auth process again.
9:18 a.m.
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
3951
days inactive
3953
days old
2 comments
2 participants
participants (2)
-
Bill Burke -
Darran Lofthouse