Bugzilla – Bug 5550
static functionality with GridShibEntityMapper
Last modified: 2008-11-11 07:56:18
You need to
before you can comment on or make changes to this bug.
I noticed the use of static methods and fields in the GridShibEntityMapper
class that were not involved in stateless utility functionality.
GridShibEntityMapper is part of an API responsible for consuming things that
link SAML and X509 identities, I believe this for example includes how the
policy for what assertion signers to trust is loaded.
The way I read the code, all instances of an authorization chain with GSforGT
that has these mappings configured will feed into one registry, JVM-wide
(because it's static).
I asked Tom about this and he suggested that this is akin to trusted CAs and we
should perhaps treat this information as not chain-specific.
We should discuss this. I'd like to record a few initial thoughts though.
1. The GT development code allows for different service and even per-operation
contexts to have different sets of trusted CAs. There are use cases for this
even from our code. For example, host certs involved in the AA query mechanism
will typically be outside the normal grid CA packages and we can isolate these
trusted CAs to just AA queries. Though it is true the trusted CAs only really
affect the authentication layer and not the subsequent authorizations, this
could still potentially either A) avoid real problems (if authorization is not
used or if the union of all CAs results in incompatible DN namespaces which
don't happen in grid CAs because of mutual agreements) or B) at least allow for
more safety with possible authz misconfigurations (or incorrect code) and such
that could not slip through in the more open scheme.
2. In my opinion, the static nature of this does have to be changed regardless
of the decisions made about container wide mappings. For one main reason, the
container != the JVM. When embedded in other containers (such as Tomcat) this
distinction becomes readily apparent. People run multiple containers side by
side in a JVM. I'm not sure if all the classloading tricks in such situations
can save one from the perils of using static methods, do they?
3. If it is agreed that it should be always container wide, I suggest we work
out a way to then implement this at the container level in the normal way -- or
at least look if this is viable. With an interceptor in the container security
config that is both configured in one place and executed in its logical place
at the container level. In the current implementation, configs from any level
(container, service, resource) are feeding into the JVM level registry, which
at first glance strikes me as the wrong place to be configuring things if it's
meant to be container wide (the mappings and the interceptor that consumes the
configuration are potentially in each of the service/resource chains being
protected by GSforGT resulting in some kind of union of all the configs). It
seems better for the administrator to configure the mappings all in one place
and not just because that is obviously more convenient. For example, what if
some of the services with configs are not invoked and their interceptors do not
run before some others are run. This could result in a situation where the
global data configured under some services don't make it into the global
Regarding thought #1, I am trying to say that there is perhaps an analagous
situation with these mappings...
Regarding thought #2, I can't seem to find an explicit statement about static
fields and classloaders (even in the specification book, 3rd edition) but I
have found several comments that do imply that static fields are per
classloader and not JVM. I don't have much classloader experience, sorry about
Thanks, Tim, for your thoughtful remarks regarding the GridShibEntityMapper. A
link to the API is provided below for reference:
Note that the GridShibEntityMapper (GSEM) is bundled with GridShib SAML Tools,
not GridShib for GT. This shows that the GSEM does not interact with the
policy layers of GS4GT (existing or future). As you pointed out, its purpose
is to link SAML and X.509 identities. Today it does this via simple mapping
files. Tomorrow, it will rely on SAML metadata. Whether it will
simultaneously support both is open to discussion.
Yes, the current GSEM model is container-wide. At the time, I didn't think it
made sense for individual services to build up their own metadata stores. I
still think this is true. Like certificate stores
(/etc/grid-security/certificates), metadata seems to be globally applicable
across the container.
By the way, I haven't tested GS4GT in other containers (such as tomcat). This
needs to be done.
Coincidentally, your suggestion to raise attribute push to the container level
is exactly what I've been asked to do here on a system at NCSA. When first
asked, I stumbled, since we had never considered this deployment option when
designing GS4GTv0.6.0. The design of GridShibPDP, for instance, is all wrong
in the face of a container-wide deployment model. That said, configuring GS4GT
at the container level makes a lot of sense. In that case, the static design
of the GSEM is even more relevant, I think.
This bug will be addressed after the release of GS4GTv0.6.0, so the former no
longer blocks Bug 5568.
This bug falls under the "SAML/Binding Tools" component (not "GT plugin") since
the GridShibEntityMapper is distributed with GridShib Common, which is
maintained by GridShib SAML Tools.