scott, sorry for the length...
* Scott Bown <[EMAIL PROTECTED]> [2007-06-19 11:01]: > We have 6 extranet applications with a few more on the > way. Currently every uses from each client shares a joint client > login. We need to separate this and have individual logins for each > user at each client. > We're wanting to implement a LDAP Directory (OpenLDAP) to store User > information with the aim to using a web Single Sign On solution across the > current and future applications. [...] > The idea is to push the burden of user management onto the client. is this web apps only? in case the clients already have their own user management (who doesn't?) you could use these in some kind of federated[1] authentication/authorisation scenario. this won't help for non-web apps, though. > We would like to implement access control, so the client super user can > say user1 can access application 1 but not application 2 and application > 3. I was thinking having attributes on each user something like > accessApp1=Y, accessApp1=N,accessApp1=N. Then checking for the attribute > when user attempts login. > Q2) is there a better way to implement customized access control. I > thought about user groups but thought i'd have to create a new group every > time I added a new application. you could either store permissions in each users entry and filter for these attributes, e.g. allowedService=Application1 (multi-valued, but you could also use just one attribute per entry and do substring searches; the former being the more standard ldap way). this allows to add new applications as *values* and spares the need to add a new attribute definition to your schema for each new application. but having users in groups always helps. depending on your situation you could either use (existing, e.g. at your clients' site) organizational or project groups or create groups specific for access management (whose members could also be derived from existing groups). wrt the need "to create a new group" for each new application: either define a new attribute in your schema (your example), define a new value for some existing attribtue (see above), or create a new group -- unless you want to grant access to each and everyone by default when you add a new application there simply is no way around it. usually no access should be given unless there is explicit permission to be found somewhere. you could also use organizational or project groups as "implicit" (bundles of) permissions, e.g. all members of the group "PublicRelations" are allowed to use these applications, "Helpdesk" may use those apps, etc. so new applications make use of existing groups without having to define anything for each new app (but this will probably get more difficult if you want to be able to handle exceptions, e.g. "all from groupA except Ann"). > My colleague suggested having the user information data stored in a > separate database and just use LDAP for username and password > information. Personally I think this adds another layer of > complexity to the solution. However manipulating the data in a > database is easier than in the LDAP directory. this also depends on the kind of data you're storing, how often it's updated and what kind of operations/requests you want to facilitate (think RFC 4515 vs. SQL SELECT and JOIN). and on the way you store the data on your clients now (in your "systems of record"). and the way you plan to move/sync/reflect/join this data to the other systems (RDBMS, LDAP, etc.). and the way people would access and update the data (web interfaces, fat clients, custom applications, standard software, etc.). and ... > Thanks for any advice or links to websites with good practices for > LDAP design. for the bigger picture I'd recommend "The role of directories in Single Sign on Systems"[2] from Victoriano Giralt, which gives an excellent overview on the state of the art wrt directories and access management. or have a look at at http://middleware.internet2.edu/dir/ (LDAP Recipe, Practices in Directory Groups, the work in Grouper and Signet, etc.), you might find a few ideas there. kind regards, -p.schober [1] for an intro to access management and federated am see e.g. http://www.jisc.ac.uk/whatwedo/themes/access_management/federation/federation_about.aspx [2] http://www.terena.nl/activities/eurocamp/april06/slides/day1/victoriano-giralt.pdf -- [EMAIL PROTECTED] - vienna university computer center Universitaetsstrasse 7, A-1010 Wien, Austria/Europe Tel. +43-1-4277-14155, Fax. +43-1-4277-9140 --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
