Skip to main content

Unexpected Behaviour ServerAuthModule AuthStatus

3 replies [Last post]
Anonymous

Hi,

I am playing around with JASPIC and custom ServerAuthModule, LoginModule,
CallbackHandler and Callbacks.
All this in combination with FORM based login.

By now I have a couple of questions, happy to find anybody able to answer
them. All examples on the web are trivial and the jaspic-provider-framework
testcase does this even better ;)

1) host:port/j_security_check doesn't trigger my SAM. I explicitly have to
post the form to the (e.g.
/private/restricted) to trigger that.
At the moment I simply post to /private/index.xhtml ... which does the job.
Is that the expected behavior? Somehow I would have expected to see all
posts to host:port/j_security_check trigger
the configured message security?

2) in case everything works fine (Subject returned from
loginModule, CallerPrincipalCallback and GroupPrincipalCallback added) and
i return a AuthStatus.SUCCESS everything works fine and the
protected resource is send to the client.

If I catch a LoginException from the LoginModule and try to return
AuthStatus.SEND_FAILURE I simply get a blank page :|
I can do something
like HttpServletResponse.setStatus(HttpServletResponse.SC_FORBIDDEN); and
the browser reports the 403 with a communication error (maybe chrome
specific behaviour)
But what I would have expected to see is the configured 403 error page or
at least the server sent 403 status page.
Same behavior with AuthStatus.FAILURE.
Any idea about that?

3) And a more general question: How to remember an already logged in user?
The validateRequest for requestPolicy.isMandatory() pages is called every
time. How is the proposed way of
_re_validating subsequent requests? Putting hashed stuff to the user
session? or simply validate the existence of a session? Does anybody has a
good pointer to GlassFish sources how this
is done there?

Thanks,
- M

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kumar Jayanti Guest
Offline
Joined: 2011-04-02

On Aug 28, 2012, at 3:52 PM, Markus Eisele wrote:

> Hi,
>
> I am playing around with JASPIC and custom ServerAuthModule, LoginModule, CallbackHandler and Callbacks.
> All this in combination with FORM based login.
>
> By now I have a couple of questions, happy to find anybody able to answer them. All examples on the web are trivial and the jaspic-provider-framework testcase does this even better ;)
>
> 1) host:port/j_security_check doesn't trigger my SAM. I explicitly have to post the form to the (e.g. /private/restricted) to trigger that.
> At the moment I simply post to /private/index.xhtml ... which does the job. Is that the expected behavior? Somehow I would have expected to see all posts to host:port/j_security_check trigger
> the configured message security?

The SAM is triggered whenever a protected URL is accessed. And it is not clear why that is not sufficient for your case ?.
>
> 2) in case everything works fine (Subject returned from loginModule, CallerPrincipalCallback and GroupPrincipalCallback added) and i return a AuthStatus.SUCCESS everything works fine and the
> protected resource is send to the client.
>
> If I catch a LoginException from the LoginModule and try to return AuthStatus.SEND_FAILURE I simply get a blank page :|
> I can do something like HttpServletResponse.setStatus(HttpServletResponse.SC_FORBIDDEN); and the browser reports the 403 with a communication error (maybe chrome specific behaviour)
> But what I would have expected to see is the configured 403 error page or at least the server sent 403 status page. Same behavior with AuthStatus.FAILURE.
> Any idea about that?

With the SAM you need to control the response. Firstly you should not use FAILURE since that is for the Client Side SAM.

Also the spec says the following (so my question to you is did you set a Failure Response Message to be sent to the client or not ?)

SEND_FAILURE
A failure occurred on the service-side (validateRequest or secureResponse) and produced a failure response message to be sent to the client.

AuthException
A failure occurred on the client-side (secureRequest or validateResponse) or service-side (validateRequest or secureResponse) without producing a failure response message.

>
> 3) And a more general question: How to remember an already logged in user? The validateRequest for requestPolicy.isMandatory() pages is called every time. How is the proposed way of
> _re_validating subsequent requests? Putting hashed stuff to the user session?
you could set a cookie in the response.
> or simply validate the existence of a session?
that may not be sufficient
> Does anybody has a good pointer to GlassFish sources how this
> is done there?

>
> Thanks,
> - M
>

Anonymous

>The SAM is triggered whenever a protected URL is accessed. And it is not
clear why that is not sufficient for your case? With GlassFish 3.1.2.2 it
looks like the SAM is always triggered, whether the URL is protected or not.
With JBoss EAP 6.0.1 the SAM is indeed only triggered for protected
resources. >> How to remember an already logged in user? > You could set a
cookie in the response. The odd thing is that in this case GlassFish indeed
doesn't remember the login by itself, but JBoss EAP does. After a successful
authentication, with GlassFish one needs to re-authenticate with the
container for every request, while JBoss EAP just doesn't call the SAM
anymore as long as the user is logged-in. I'm not sure who's at fault here,
but it's a remarkable difference.

--

[Message sent by forum member 'arjan_t']

View Post: http://forums.java.net/node/889627

arjan_t
Offline
Joined: 2010-06-01

>The SAM is triggered whenever a protected URL is accessed. And it is not clear why that is not sufficient for your case?

With GlassFish 3.1.2.2 it looks like the SAM is always triggered, whether the URL is protected or not. With JBoss EAP 6.0.1 the SAM is indeed only triggered for protected resources.

>> How to remember an already logged in user?
> You could set a cookie in the response.

The odd thing is that in this case GlassFish indeed doesn't remember the login by itself, but JBoss EAP does. After a successful authentication, with GlassFish one needs to re-authenticate with the container for every request, while JBoss EAP just doesn't call the SAM anymore as long as the user is logged-in.

I'm not sure who's at fault here, but it's a remarkable difference.