directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: TripleSec and jacc
Date Fri, 22 Dec 2006 19:01:29 GMT

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>


Mime
View raw message