Hi,
On Thu, May 21, 2015 at 4:06 PM, Ron Monzillo <ron.monzillo_at_oracle.com>
wrote:
> 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.
>
Having such non standard option is a bit unfortunate perhaps, as these
typically tend to complicate both testing and using the technology.
But, what's the exact nature of this principal mapping here? When I read
the documentation regarding the String form of the CallerPrincipalCallback
it sounds like the intend is to have something that closely resembles group
to role mapping. E.g.
E.g.
The SAM puts "John" in the CallerPrincipalCallback, and then
request.getUserPrincipal().getName() returns "J.Harrison".
Is that the idea?
I'm less sure what principal mapping means for the principal form of the
CallerPrincipalCallback. Does it mean that when I put in:
new org.test.MyPrincipal("John")
that request.getUserPrincipal() is allowed to return:
com.vendor.Principal("John")
or
com.vendor.Principal("J.Harrison")
or
org.test.MyPrincipal("J. Harrison")
or something else?
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.
>
Indeed, that was going to be my next question ;) I understand that the
principal that was put into the CallerPrincipalCallback needs to be one of
the principals that's stored inside the Subject.
Designing a test for this has unfortunately proven to be really difficult,
to downright impossible. The problem is that a JACC provider can't be
installed from an application archive (as is possible for a JASPIC SAM).
The environment variables (-D options) may be standardized for JACC, but
the location where to put the implementation classes unfortunately is not.
For some servers, notably Geronimo and JBoss, it proved to be impossible to
find a location where to put these classes or jar.
> 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.
>
Yes, that's clear.
> 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,
>
Okay, then I'll add a test for these two cases. It would not be a complete
test, but those two APIs should at least work then.
I did a quick manual test on WebLogic 12.1.3, and there too the principal I
passed in the CPC was not returned from getUserPrincipal. Instead a
WebLogic specific one was returned, but with the correct return value from
getName() (just as in the GlassFish case).
Thanks for your answers!
Kind regards,
Arjan Tijms