On Dec 21, 2006, at 1:59 PM, Alex Karasulu wrote:
Hi David,
My comments are in line ...
David Jencks wrote:
Now that triplesec is imported I started looking at the code with
an eye to making it more jacc-friendly. I started with updating a
bit of the build, mostly creating a dependencyManagement section
and a pluginManagement section in the root pom to track all the
external dependency and plugin versions. I also updated to
current apacheDS and updated a few other dependencies. See DIR-198
Unfortunately the day before you filed this JIRA I had done similar
things to make triplesec at least compile. I created the
dependencyManagement section as well. So when I went to apply your
patch I got massive rejections.
Is it possible to resubmit the patch after updating your working
directory. I apologize for this inconvenience.
No problem, glad to see you are working on this too :-). I've
provided an updated patch DIRTSEC-2-2.patch. I'm not certain it will
compile without all the DIRTSEC-1 changes I have locally.
You missed a few versions, and I added a pluginManagement section and
changed to using the geronimo servlet/jsp specs -- I prefer to have
the artifact Id indicate which spec version I am using.
It would be great if a committer with IDEA could spend a few
minutes and666 change the package names to live at apache :-)
although warning me first would be even better.
I could do this soon. Perhaps we should first get your patch applied
then I can fix the package names immediately.
If we can coordinate thoughts on DIRTSEC-1 first that would be great
-- that patch is getting large enough so moving it would be a pain.
At this point I have a question and a plan :-)
Okie.
I don't understand how application id is supposed to relate to a
Subject or a profile or a user. Currently it looks to me as if
when a user logs in they are restricted to working in one
application. IMO this is sort of ridiculous :-), so probably I'm
missing something important here: explanations welcome.
Let me give some background on Triplesec's AuthZ policy store and it's
schema.
The ideas in tsec were really simple. You have the following
entities:
Application
Role
Permission
Profile
User
An application can be anything and need not be a web application.
It's
any situation where you have to *apply* a set of permissions to
control
access to resources or operations within some domain.
All permissions are specific to a particular application (a.k.a.
domain). Permissions are merely labels inside triplesec without
semantics.
Permissions (their names) are added to Roles as grant attributes. By
doing this any user's profile associated with a role inherits the
grants
associated with the role. This is how Tsec does RBAC. Roles also are
application specific since they hold application specific permissions
and only make sense in that application.
Users are users as we think of them generally. They are not defined
specific to any application. However in order for a user to be
allowed
to access an application that user must have a AuthZ profile defined
within the application. This brings us to profiles.
Profiles represent AuthZ profiles for users. A profile is associated
with a user with a special *'user'* attribute. Profiles contain a set
of roles which allow profiles to inherit permission grants from those
roles. In addition to this fine tweaking is allowed using a
permission
set for denying certain permissions and one for adding additional
grants
not included via role assignments.
So to get to your question: a user can access any number of
applications
however that user has a different profile for each application they
access.
I'm biased from working with jacc, but I would tend to rename
applicationId to policyContextId since the scope of whatever is
associated with such an id may not always be an application. In
particular jacc deals in policyContextIds, one per j2ee
application module.
We could rename application to context to be explicit about the fact
that permission and role definitions are specific to some domain
and not
to a web or swing application for example.
Ersin also had ideas about this at some point. Perhaps he can
elaborate
on that here.
I'd certainly appreciate that. In jacc, policyContextId is typically
smaller than a whole enterprise application: each war or ejb jar in
an ear gets its own policyContextId. I'm inclined to proceed now by
using the applicationName as the policyContextId and later figure out
how to make administration reasonable. Basically this is because
this splits up the permissions into smaller chunks so presumably they
can be evaluated faster. The alternative would be to introduce
another layer in the triplesec data model for policyContextId. I
think this is undesirable unless we run into big problems doing it
the simple way :-)
On to the plan....
1. Depending on the explanations for the above question, either
keep a Profile per applicationId and have SafeHausPrincipal
include a map of applicationId >> Profile or have the Profile
contain the map of applicationid >> ApplicationProfile (or
PolicyContextProfile).
Sounds to me like since the user logs into the J2EE app server and
*NOT*
into a particular application you need access to all profiles (for all
apps the user participates in). Is this correct?
yes, exactly
If so then we can make it so you can access all the user's profiles
through some API ... essentially exposing this appId to profile map
per
user that you speak of above.
I'll see if I can do this next.
2. The current Permission class is not a
java.security.Permission. I propose to rename it StringPermission
(since it works on string equality), extend
java.security.Permission, and introduce a
StringPermissionCollection. BTW I don't understand why triplesec
Permission includes the applicationName.
First off a tsec permission includes the app name because permissions
are specific to an appication. Perm xyz only makes sense wrt the app
that it was defined for. Does this make sense?
No :-)
I think you are duplicating information redundantly. You'll never
get to the point of checking a permission unless you navigated to it
from the correct application. The JACC ejb and web permissions also
don't make sense outside a particular application, but they don't
include the PolicyContextId in them for this reason.
Similarly I don't think it makes sense to have the application name
in Role nor the permissions stored directly in ldap.
Regarding calling it a StringPermission we can do this yeah.
3. Replace all use of the triplesec Permissions class with
java.security.Permissions. This uses the
StringPermissionCollection class for quick implies calculations
and allows use of all other permission classes such as those used
in jacc. This is going to replace a bunch of proprietary
triplesec methods with "implies"
This much should be pretty straightforward and keep functionality
pretty much the same.
Cool I think I'm down with this approach that bridges J2SE security
with
tsec permissions.
I implemented this in the latest DIRTSEC-1-2.patch. I also added
denied permissions to Role. All the tests seem to pass (except a
couple (web app??) tests I don't understand) but I haven't figured
out how to try it out yet :-)
4. try to understand how the current StringPermissions are being
stored in ldap and figure out how to store the permissions needed
for JACC. IIRC Alex mentioned StateFactory as an elegant solution.
Yeah we can figure something out. We don't necessarily need to just
implement a StateFactory but it is a solution that might work well
with
the JNDI access model. However keep in mind this is just merely a DAO
design matter and not that big of a deal of us I think.
At that point it should be really easy to use triplesec as a jacc
provider in at least geronimo.
How plausible is this? Comments?
Very. I don't think it will be hard to do. Perhaps we can define a
special permission object class that serializes Java permission
objects.
In the end though it's perhaps best to not serialize but devise some
text based representation of the different kinds of JACC permissions.
This way the entries stored in the directory are human readable when
accessed and managed via LDAP. We may define new sub objectClasses
(LDAP) for these new kinds of permissions which include special
attributes for them like the URL pattern for a JACC web permission
(sorry forget the exact name for this permission).
I'd rather follow this path also. I'll be trying to figure out how
ldap schemas work now :-)
I opened DIR-199 and am attaching the start I made on (2) so
others can look at what I'm up to. This is not finished yet by any
means.
I'm here to work with you and help out. First off I recommend we fix
this small issue with your latest patch due to my commits the day
before.
Then we can rename the packages and sort out other minor issues.
Might be better to apply the current DIRTSEC-1 patch if you are OK
with it, it's getting fairly large :-)
BTW we need to cleanup the schema and switch to using Apache
enterprise
numbers for the OIDs in the LDAP schema but you need not worry
about this.
Looking forward to working with you on this David.
Likewise!!
thanks
david jencks
Thanks,
Alex
<akarasulu.vcf>
