James Mason Adventist Health Programmer/Analyst 916.783.2576 [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 05/26/04 6:11 PM >>>
>Yes, JAAS could be used. I didn't think of it before because Slide seems >to require a little bit more. You need to expose these user nodes and >provide some standard properties. Is this really needed? I actually think JAAS might work well for this. The only issue is Slide looks up user/role association by going to the role and seeing if the user is in it (rather than looking at a user's roles). Also, in order to assign a role as the subject of a permission on an object you need a list of roles. I'm really not familiar with JAAS, but it would need to support getting a list of all roles in the system as well as role-to-user lookups in order to work in Slide. >> >> PS there are also some diadvantegs to just user/password storage >> changes, promarily that from a admin point of view you now have two >> points of admin LDAP for user name and passwords and other permisssions >> and WEBDAV/Slide for ACLs which isnt exactly a global admin view. >> >> Al > >Permissions are difficult to define outside the application domain. For >example, JBoss uses JAAS and you can write a JAAS login module. But it >only authenticates a user and retrieves its roles. Permissions are >handled separately because they have meaning only to the application and >it depends on what they are applied to, which is also an internal >concept of the application. What I'm saying is that you probably have to >go to the specific application to do permission administration anyway. To illustrate Carlos's point: Slide has three type of principals (that I've seen), users, roles and actions (also groups, but I haven't played with those). In order to store permissions in a central location (LDAP) the action nodes would need to be stored there along with the users and roles. Since the action nodes are very specific to Slide, none of the other applications using the LDAP server would be able to make use of them. This makes them clutter (as far as LDAP is concerned) and should probably be moved into the application. As for administration, if you've got a central location for storing all of your user accounts then you've already got an admin tool for it. It's really nice to have a single interface for managing users, managing roles and managing permissions, but in my experience there are always problems with providing a 3rd party management solution for an only partly standardized user repository (LDAP directories are very flexible and can be setup in many different ways). Since anyone with an LDAP server already has an LDAP admin tool it seems like more effort than it's worth to try to abstract the LDAP structure into something that makes sense for user/role management in an application. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
