Hi,
On Thursday, May 21, 2015, Ron Monzillo <ron.monzillo_at_oracle.com> wrote:
> 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.
>
Okay, I haven't studied in depth what resource adapters exactly do here,
but I'm fairly sure that for the Servlet Container profile no container
does this by default. The only container that does something *like* this is
WebSphere/Liberty, as they demand that every name value passed in the CBH
exists within their proprietary artifact called "user registry".
It was established earlier that this is not fully spec compliant, but if
value mapping is allowed by default then a very unfortunate consequence is
that it could also be demanded by a container that a name mapping is
provided. This is a bit like mandatory group to role mapping, only worse.
The one thing making it a bit less unfortunate is that the spec says that
it must be possible to disable this.
Especially for the proposed functionality in the security EG, having a
default allowed case of something container specific is a huge problem I'm
afraid.
Perhaps the best solution is to "simply" provide a portable API to disallow
this mapping? Maybe via an extra option in the AuthConfigFactory?
> 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.
>
Type 1 is what seemingly all vendors currently do, and GlassFish and
WebLogic do for sure (without any option I think to turn this off). When
using the principal form, people seem to perceive this as a "bug", "flaw"
and "fundamental problem" (see e.g.
https://twitter.com/Tsarev_Oleg/status/598803007485169664).
As with the value mapping, I don't think there's currently any vendor that
explicitly does 2 and 3.
> 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?
>
Yes, a few actually ;)
The first would be to have an AuthConfigFactory just like exists today for
JASPIC. The default (global) JACC provider would be mandated to delegate
everything to an application scoped JACC provider if one exists for a
specific application, or for every application if the JACC provider (both
config and policy) were registered with a "null" as is the case in JASPIC.
Via the null value it would be possible to deploy a JACC provider by having
it as the only code in a special war, and then have it globally available.
The second option would be to have a special archive for the JACC provider
code, like a .rar archive that JCA uses. Deployment of this new archive
type would install the JACC provider for the entire container.
The third option would be to mandate that the container makes a special
directory available in the product installation where it MUST scan for the
classes that are given via the -D options (this is what GlassFish already
does).
> 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.
>
Well, actually, a few containers do seem to make this possible (more or
less). Geronimo for instance asks the user to configure a specific type as
the user principal and group principal. Geronimo provides 2 default
implementations for both of these, but if I'm not mistaken you can use
whatever type you want.
See the Geronimo entry in step 7 here:
http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html
Kind regards,
Arjan Tijms