I had a great conversation with Alex Karasulu at Apachecon about
integrating TripleSec into geronimo as a JACC provider. I think this
will be pretty easy to do and provide a very powerful security
management capability for geronimo. I'll try to describe my
understanding of our conclusions about what needs to be done. My
understanding of TripleSec is based entirely on Alex's brief
descriptions so any inaccuracies should be blamed entirely on me :-)
Data Model
The TripleSec datamodel needs some changes to fit with java
permissions and the j2ee permissions categories of unchecked,
excluded, and role-mapped. To review for those who may not have
reviewed their JACC recently :-) the unchecked and excluded
permissions apply to all users without regard to who they are or what
roles they might be in whereas the role-mapped permissions grant
permission based on the users current roles.
- permissions. IIUC the current TS permission model uses
String.equals to implement Permission.implies(Permission). This
doesn't work well with things like web permissions where you can be
granted permission to see /context-root/public/* but excluded from
seeing /context-root/public/area/secret/*. I think that it will be
much more powerful to support storing actual java Permission objects
in LDAP and delegating the implies to the actual Permission
implementation. Use of Permission.implies is required for a JACC
implementation. I think simply serializing the permissions and
saving the bytes as well as saving the toString() name for
identification will work OK for an initial implementation: Alex
suggested using StateFactory and ObjectFactory for a more
sophisticated implementation that would store more meaningful info.
-role-mapped permissions are supported well by TS role-principal
mapping and profiles.
- unchecked permissions are not currently supported by TS. I think
these can be supported by having an "unchecked" role and granting it
to all users.
- excluded permissions are not currently supported by TS. I think
the best way to support them is by modifying Profile to include a set
of denied roles along with the existing granted roles and granted and
denied individual permissions. The excluded permissions can be
modeled as a role denied to everyone.
With this proposed change Profile would contain a userId, an
applicationId, a set of granted roles, a set of denied roles, a set
of granted permissions, and a set of denied permissions.
The effective permissions set needs to contain both granted and
denied permissions since a denied permission will generally not
exactly match any granted permission. So, the granted permissions
would be the union of permissions from the profile's granted roles
together with the individual granted permissions, and the denied
permissions would be the union of permissions from the profiles
denied roles together with the individual denied permissions.
The TS LoginModule needs to generate a subject from which the granted
and denied permissions can be extracted for each applicationId. The
simplest way I can think of to do this is to use a TSPrincipal that
contains a map of applicationId to an object containing the granted
and denied permissions.
The JACC policyContextId seems to correspond well to the TS
applicationId.
JACC integration.
We can divide this into runtime policy enforcement and deployment
time policy configuration.
-runtime. Following normal methods the user logs into a security
realm that uses a TSLoginModule producing a TSPrincipal containing
the effective permissions as described above. When a permissions
check is done, as usual the decision is delegated to the
PolicyConfiguration for the policyContextId: this checks the
permission in question against first the denied permissions and (if
not denied) the granted permissions, per the following simple code:
public boolean implies(ProtectionDomain domain, Permission
permission) {
Principal[] principals = domain.getPrincipals();
if (principals.length == 0) return false;
for (int i = 0; i < principals.length; i++) {
Principal principal = principals[i];
if (principal instanceof TripleSecPrincipal) {
PermissionsHolder permissionsHolder =
((TripleSecPrincipal)principal).getPermissionsHolder(contextID);
Permissions denied = permissionsHolder.getDenied();
if (denied.implies(permission)) return false;
Permissions granted = permissionsHolder.getGranted();
//only look for one TripleSec permission
return granted.implies(permission);
}
}
// if no TripleSec principal found, deny access.
return false;
}
This part will just work in geronimo after configuring a security
realm using the TSLoginModule and specifying
TSPolicyConfigurationFactory as the JACC provider.
-deployment time. Currently geronimo waits until the application
starts to install the permissions into the JACC provider. I think
this is primarily because we don't have a persistent store for these
permissions, although the spec might have something to say about this
as well (I don't remember). Since TS definitely has a persistent
store, I think it would be more appropriate to install the spec
permissions when the application is converted into a geronimo module
(car file). This gives the security administrators time to configure
the users profiles. I don't know when it would be appropriate to
remove an applications permission info from TS, nor do I have an idea
how redeployment with changed permissions might work. I'm hoping
that after we get the basics described above done it will be clearer
how to deal with application evolution.
----------------------
I spent a few minutes and wrote up the start of most of the classes
needed for the integration. I put them at https://svn.apache.org/
repos/asf/geronimo/sandbox/triplesec
TSPolicyConfigurationFactory --- this is probably complete.
TSPolicyConfiguration -- the implies method is probably complete.
The methods for adding and removing permissions need to be hooked up
to TS. It's not entirely clear to me exactly what the open(remove)
method should do. This is basically the application evolution
question I mentioned above, and we probably don't have to answer it
until we get everything else working.
TSPrincipal -- this is a very simple implementation of something that
meets the needs of the TSPolicyConfiguration. If I understaood Alex
correctly the existing TSPrincipal gets updated when the data in LDAP
changes. I'm hoping that the additional complexity of having both
granted and denied permissions will not make this significantly harder.
TSSecurityBuilder. This is a Geronimo Security builder. Basically
it has no knowledge of TS whatsoever and just uses the JACC
interfaces to install the spec defined security info into the
PolicyConfigurations during deployment. There are a couple of
methods that I don't know how to implement, and they remind me that
at last years ApacheCon Simon Godik pointed out that all Subjects
used in geronimo should be derived by logging some user into the
appropriate security realm. If we had taken his good advice these
methods would not be there to cause problems. I think its time we
changed to this model. Meanwhile I don't think that the
implementation hole will affect TS integration" its used for
specifying default users and run-as subjects.
The TSSecurityBuilder IMO should be moved into geronimo core since it
can be used with any jacc provider that provides a persistent store.
The other classes I think should move to TS. I plan to be working
with Alex and anyone else who is interested over the next few weeks
to get this into a working state. Ideally I'd like to see it as a
geronimo plugin released with geronimo 1.2.
I also opened GERONIMO-2497 to help tracking progress on this.
------------------
On a mostly unrelated note I recall that jetspeed2 has a security
administration portlet app for their security system that has some
feature overlap with TS. I wonder if it would be possible to use
this as a start for developing a web front end for TS.
thanks
david jencks
