> - - How do I tell the container what Subject should
> be used for subsequent authorization decisions? From
> the spec it sounds like I should add the
> authenticated Principals to the container-supplied,
> client subject.
that is correct. in effect, the container has given you the subject
that it will be using for its access decisions.
as defined by section 3.8.3.1 "validateRequest Before Service Invocation"
of the Servlet Profile, your SAM must use the CallbackHandler
supplied to it by the container, to handle a CallerPrincipalCallback.
This will ensure that the container will be able to interpet the contents of
the subject to select the user principal to associate with the request.
If in your SAM you also want to add principals to be recognized as group principals
by the container, then you should add them using the GroupPrincipalCallback.
>
> - - Once a client is authenticated should my SAM
> cache the Principals in the session object?
It could, but that could be an issue, especially if your application could use the same technique to
in effect, authenticate itself. IMV, there are 2 ways for the SAM to produce stateful authentication results.
a. The SAM (or the underlying system with which it interacts)
could maintain a private correspondence between session ids
and authentication state/attributes. The standard profile is somewhat skewed towards
this use model. iow, it assumes that the sam is in effect a client of an authentication system that
fully supports sessions, timeouts, etc. In fact the primary reason why the SAM is called on
every request, is to ensure that this model is feasible, e.g., there is an opportunity to
evaluate session status on requests that would not otherwise require authentication
(see the footnote at the end of page 31, and related discussion of sessions in other parts of
the spec).
b. the SAM can rely on the session machinery of the encompassing container. To do the latter in glassfish, the SAM adds a server specific property to the MsgInfo map (In the next rev of the profile, I will propose a portable way to achieve the same effect).
static final String DELEGATE_SESSION_INFO_KEY = "com.sun.web.RealmAdapter.register";
messageInfo.getMap().put(DELEGATE_SESSION_INFO_KEY, true);
>
> - - On each request, how will my SAM know if
> authentication has already taken place? It appears
> the container-supplied client Subject is new with
> each request and the server Subject is null.
>
> - - How are sessions and time-outs to be managed?
Please see above.
Ron
[Message sent by forum member 'monzillo']
http://forums.java.net/jive/thread.jspa?messageID=393489