On 5/21/15 11:25 AM, arjan tijms wrote:
> Hi,
>
> On Thu, May 21, 2015 at 4:06 PM, Ron Monzillo <ron.monzillo_at_oracle.com
> <mailto: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 call the above an example of a value mapping, where a mapping to
different principal implementation class,
I call a type mapping.
when the name based callback is used, the value must be preserved if the
container is configured NOT do any mapping
when the name callback is used, the container always establishes the
principal type, and when mapping is allowed,
it may perform also perform value mapping. For example, the CBH passed
to an inbound resource adapter, might do
value mapping.
when the principal based callback is used, the value and the type must
be preserved if the container is configured NOT to do any mapping
when the principal callback is used while mapping is allowed, either or
both forms of mapping (value and/or type) may be
performed by the CBH. mapping to a container specific principal type
while preserving the value appears to be a common
behavior.
>
> 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:
>
> 1) com.vendor.Principal("John")
>
> or
>
> 2) com.vendor.Principal("J.Harrison")
>
> or
>
> 3) org.test.MyPrincipal("J. Harrison")
>
> or something else?
>
all should be possible, along with a 4th case,
org.test.MyPrincipal("John") for when the container is configured to NOT do
any mapping when the CPCB is used.
type 1, 2, and 3 would depend on mapping being allowed. Type 2 and 3
would likely depend
on the configuration of some very specific mapping info, and thus would
be less likely to occur than 1.
I don't think type 3 would be very likely to occur, although I don't see
it as being prohibited (when mapping is allowed).
> 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.
do you have any suggestions on how to change the requirement?
removing the configurable aspect, would certainly make it easier to test.
a related problem is that principal-2-role mapping, where it is used,
does not
tend to be specific to type, so custom principals cannot typically be
represented in
role mappings. As discussed, a policy provider does not need to rely on the
role mapping facilities of the container, but some will want to do that.
in combination, custom principals really are only workable if: you are
not using the
container's principal-2-role mapping facility to map caller principals
either because
1. your reliance on the container's role mapping facility is limited to
mapping based on
group names (that are materialized as container specific group
principals), or
2. you are not relying on the container's role mapping facility at all.
You handle the
equivalent of p2r mapping within some other system (e.g. a JACC provider
that
you integrate) in your container.
Ron
>
> 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