|
[ Pobierz całość w formacie PDF ]
.For this reason, creating anorganizational unit specifically for this application (for example, ou=OnlineBrokerage,o=forethought.com) and then adding users to that structure isn't a very good idea;the directory tree would likely end up cluttered with various applications, with userinformation stored under each.This method of storing all users under a generic People branchallows you to use the same user information for a variety of applications.The default object used to store a person, inetOrgPerson, contains attributes for all theinformation you'll need to record for users: a username, a password, and the ability toreference the user object from groups (which I'll talk about next).In this case, then, thedefault LDAP schema suits our needs perfectly.You can use the uid attribute for theusername, and the userpassword attribute for the password.All other fields can be leftunused, as they aren't really relevant to the Forethought application.However, the inetOrgPerson object isn't quite perfect for this application's needs; while it hasattributes for all the information you need to store, the attributes we want to use (for user IDand user password) are not required attributes.The only required attributes for theinetOrgPerson object class are sn (the surname or last name of the user), cn (the commonname or first name of the user), and objectclass (filled in automatically by the directoryserver).You need to add the username and password attributes to the set of requiredinformation to ensure no users are created without at least a username and password.3.3.1.1 Structural constraints versus programmatic constraintsAt this point, you can either add constraints to your LDAP schema at a physical level (like theconstraints in Section 3.2) or decide to enforce the constraints later at a programmatic level.As in the database design, it is preferable to add these constraints into the LDAP schema.Thisapproach ensures that no invalid data gets into the directory server and makes programmingtasks easier down the line.However, you don't have much control over this particular design.First, it is a bad idea to actually change the default inetOrgPerson object class itself.I will7Almost every directory server's default installation will have a pre-built People organizational unit, with a DN of ou=People,o=forethought.com.If your server does not, consult Appendix C for details on creating that unit.50 Building Java"! Enterprise Applications Volume I: Architecturetalk a bit more about this in the next section, but for now suffice it to say that changing thedefault object classes is a bad idea, and that extending these object classes and creating newones is much better.Doing so also keeps the core directory server compatible with otherstandard directory server schemas.However, I already mentioned that the proposed parent class, the inetOrgPerson object class,has the uid and userpassword attributes as allowed attributes.Extending this object does notallow us to change those from optional to required attributes, as that would essentially breakthe inheritance chain.This rule is similar to the Java rule that doesn't allow member variablesin a parent class to be made more accessible in a derivative class (such as moving fromprivate to protected, or protected to public).Its consequence is that extending theinetOrgPerson object class and then adding additional constraints on existing attributesimpossible.So in this case, you have to use programmatic constraints instead of physicalones.This means that the default inetOrgPerson object class will suffice as-is for our needs.Next, I will look at extending object classes and creating new ones in order to handle users'authentication data.3.3.2 Permissions and RolesWith the user object class in place, you can now tackle permissions and roles that determinehow users can interact with the Forethought application and what portions of the applicationthey can access.As in the case of storing users, it is a good idea to see if any existingstructures map well to the application requirements.In this case, we need an object class tostore a single permission, and then another object class that represents a role, which should beable to reference multiple permissions.Finally, a role should be assignable to multiple users,creating the last link between users and their individual access rights.Default LDAP schemas do not provide any sort of permissions object class, but the defaultobject class groupOfUniqueNames seems to be a close match for a role
[ Pobierz całość w formacie PDF ]
zanotowane.pldoc.pisz.plpdf.pisz.plhanula1950.keep.pl
|