Hi Arjan,
On 5/20/15 4:09 PM, arjan tijms wrote:
> Hi again,
>
>
> there are 2 forms of the CallerPrincipalCallback. A compatible
> container is required to be "able to be configured" to handle
> the principal based form of the Callback, without doing
> mapping to a container specific principal. I admit there have
> been problems in getting this to be supported properly.
>
>
> Wow, I've obviously seen that form, but I never truly realized
> that the exact Principal instance passed there is the one that
> should appear in the principals collection of the Subject and I
> assume also be exactly what e.g.
> HttpServletRequest#getUserPrincipal returns?
>
> I'm going to retest this soon, but I've got a sinking feeling that
> more than a few servers ignore this completely. When I tested what
> this method was supposed to do in 2012 on EAP 6, I'm fairly sure
> it didn't use the Principal as given, just its name.
>
> But why not just add a TCK test for this? Have the test configure
> a SAM that passes in com.test.MyPrincipal("test"), then using
> either JACC or Servlet (or both), test if the rightPrincipal type
> is available?
>
> I think the tests will be improved in this area (for upcoming
> releases).
>
>
I agree there should be a test for this, although it's important to keep
in mind the "it must be possible to configure..." aspect
of the requirement as specified. Jaspic didn't standardize how to do the
configuration, which will mean that any testing will
need to include instructions stating that the appropriate proprietary
configuration must be done before running the test.
also, galling getUserPrincipal and getCallerPrincipal would be a good
basis for such a test, but the container is also required
to use the custom principal in its container access decisions (you can
find that in the jaspic spec). In a JACC compatible
environment, you can get the principals that were used in the container
access decision by using the subject policy context
handler defined by JACC.
regarding the jira issue, and the proposed fix... I know that some work
was done to capture a custom principal within the
webPrincipal, such that it could be applied in the container access
checks, and returned by getUserPrincipal. The fix proposed
in the issue, appears to leverage that work, and may be sufficient to
complete the fix in glassfish...but as I mentioned previously
a complete fix needs to do more than just effect the return value of
getUserPrincipal.
> This issue recently came up again on Twitter among others, and it
> appeared that there was an existing GlassFish JIRA entry for this. It
> indeed doesn't work on GlassFish. See
> https://java.net/jira/browse/GLASSFISH-16587
>
> As I wanted to add a test for this case anyway, now seems like an
> especially good moment. Before I add the test I would like to verify
> the assumption though:
>
> If the principal based form of the CallerPrincipalCallback is used
> such as discussed above and such as outlined in GLASSFISH-16587,
> should it then indeed be the case that in a Servlet
> HttpServletRequest#getUserPrincipal as well as in an EJB
> EjbContext#getCallerPrincipal both return that exact principal?
>
yes, with the configuration caveat I mentioned above
> I.e. if a pass a new com.test.MyPrincipal("test"), should
> HttpServletRequest#getUserPrincipal and EjbContext#getCallerPrincipal
> both return com.test.MyPrincipal("test")?
>
yes, and thanks for your attention to this,
Ron
> I'm fairly sure this is the case based on our previous discussion as
> well as the comment in the GlassFish issue "yes this is a known issue
> and we made some work on it to get the behavior you are looking for.
> It is still not committed, more work to do.", but just wanted to
> double check.
>
> Kind regards,
> Arjan Tijms
>
>