1 / 60

More Than a Robust and Scalable LDAP Group Store Matthew Ling ( matthew.ling@ucalgary )

More Than a Robust and Scalable LDAP Group Store Matthew Ling ( matthew.ling@ucalgary.ca ) June, 2004. Agenda. Just-in-Time LDAP Group Store (JIT LDAP) Comparison to PAGS Institutional Group Implementation Issues Identity Amalgamation. JIT LDAP.

bell-wright
Télécharger la présentation

More Than a Robust and Scalable LDAP Group Store Matthew Ling ( matthew.ling@ucalgary )

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. More Than a Robust and Scalable LDAP Group Store Matthew Ling (matthew.ling@ucalgary.ca) June, 2004 Information Technologies

  2. Agenda • Just-in-Time LDAP Group Store (JIT LDAP) • Comparison to PAGS • Institutional Group Implementation Issues • Identity Amalgamation Information Technologies

  3. JIT LDAP Just-in-Time LDAP Group Store Information Technologies

  4. Motivation – Authorization (1) Authorization: • Answers these question: (bottom-up) • Which groups does this person belong to? • Which groups does this sub-group belong to? • Does not answer these questions: (top-down) • Who belongs to this group? • Which sub-group belongs to this group? Information Technologies

  5. Group A Group B Group C SG A.1 SG A.2 SG B.1 SG C.1 SG C.2 SG C.3 SG A.1.1 SG C.2.1 A B B C C A Motivation – Authorization (2) All LDAP Groups Group/Subgroup Person Information Technologies

  6. Motivation - Size • Group has a large membership (1,000+) • Basic groups: faculty (~2,000 ), support staff (~3,000), active student (20,000+), alumni (???) • Sub-groups (~1,000) Information Technologies

  7. Motivation - Reusability • Applications share group information via LDAP • Portal and web applications share groups • LDAP attribute value is the name of a group (e.g. which department a person belongs to?) Information Technologies

  8. Motivation - Flexibility • Supports multiple LDAP attributes • classification: student, faculty, support staff etc • particulars: department, course, etc • Specify relationship among values of an LDAP attribute • flat values -> hierarchical relationship Information Technologies

  9. Motivation - Manageability • LDAP attribute with 100+ values (e.g. course) • Automatic discovery of new values • not required: exhaustive group name list • Automatic derivation of relationship among values • not required: complete subgroup relationship map Information Technologies

  10. JIT LDAP - Basics • uPortal compatibility: 2.1.x, 2.2 • Minimalist and yet all-inclusive approach • (Minimalist) creates a user’s groups on-demand as (s)he signs on • (Minimalist) “learns” groups gradually in a need-to-know basis • (All-inclusive) A value of an LDAP attribute is a group • Group Manager/Permission Manager compatibility • static group/subgroup definition is available • Group name/membership definition delegated to external agents, i.e., no “business knowledge” • Package: http://www.ucalgary.ca/~mling/uportal/jitldapgroup/ Information Technologies

  11. Group A Group B Group C SG A.1 SG A.2 SG B.1 SG C.1 SG C.2 SG C.3 SG A.1.1 SG C.2.1 A B B C C A JIT LDAP – JIT or Not All LDAP Groups Group/Subgroup Person Information Technologies

  12. Group A Group B Group C SG A.1 SG A.2 SG B.1 SG C.1 SG C.2 SG C.3 SG A.1.1 SG C.2.1 A B B C C A JIT LDAP – non JIT All LDAP Groups • Group and subgroup definition are invariant but person membership can change • Load all group members together Group/Subgroup Person Information Technologies

  13. Group A Group B Group C SG A.1 SG A.2 SG B.1 SG C.1 SG C.1 SG C.2 SG C.3 SG C.3 SG A.1.1 SG C.2.1 A B B C C A JIT LDAP – JIT All LDAP Groups • Group and subgroup are created as needed • Group members are added incrementally • Partial view of group/subgroups - (some may not be visible) Information Technologies

  14. LDAP filter: uid=${key} LDAP attribute name JIT LDAP - Configuration (1) <JitLDAPGroupStore> <config> <url>ldap://ldap.univerity:389/ou=people,o=some.university</url> <bindDN>cn=manager,ou=people,o=some.univesity</bindDN> <bindPassword>manager-password</bindPassword> <keyfield>uid</keyfield> <keyvalue>${key}</keyvalue> <retention-time>180</retention-time> </config> <group attribute=“department” /> </JitLDAPGroupStore> Information Technologies

  15. JIT LDAP - Configuration (2) • When a user signs on, a LDAP search is performed • All groups associated with the user are created (once) automatically • A group is also created (once) by • Look up a person in the group via Group/Permission Manager • Name conflict amongst LDAP attributes: • prefixed by LDAP attribute name Information Technologies

  16. Auto-create groups JIT LDAP - Configuration (3) Information Technologies

  17. JIT LDAP – Implications Addition/Deletion of a group could become “fuzz” • Add a group: • (Implicit) A person has the group name • (Explicit) Include programmatically • Delete a group: • (Implicit) No person has the group name and regular flushing of cached group entries • (Explicit) Exclude programmatically • No distributed locking or broadcasting during addition/deletion Information Technologies

  18. JIT LDAP - Group Manager Integration • default super group “<attribute name>:”, e.g., “department:” • add the super group of an attribute to the group “Everyone” • all groups become subgroups of the default super group • pre-defined groups are defined as follows <group attribute=“department” > <subgroup-tree> <subgroup name=“Department of Civil Engineering”/> <subgroup name=“Department of Drama”/> </subgroup-tree> </group> Information Technologies

  19. JIT LDAP - Subgroup Relationship • define a logical sub-group: the group name is not an LDAP attribute value • define subgroup hierarchy <group attribute=“department” > <subgroup-tree> <subgroup name=“Faculty of Engineering”> <subgroup name=“Department of Civil Engineering” /> </subgroup> ......... </subgroup-tree> </group> Information Technologies

  20. default attribute super group logical/real groups JIT LDAP – Group Hierarchy Information Technologies

  21. JIT LDAP – Design (1) Portal Group Service Terminology • service name – the identifier of an external group store • group key : unique within group store • together with service name uniquely identify a group • typically, an abstract key (i.e. data-less, meaningless) • used by Group/Permission Manager • group name: a descriptive name • may not be unique • Group/Permission Manager GUI displays it in replace of the group key Information Technologies

  22. JIT LDAP – Design (2) JIT LDAP Design • group key = LDAP value prefixed with the attribute name <LDAP attribute name> ‘:’ <LDAP value> • uniqueness because of the prefix and the nature of data • no abstract key management required • group name = group key • no group name management required Information Technologies

  23. JIT LDAP - Permission Manager Implication Permission manager: permission grant/deny by principal key principal key = <service name>.<group key> = <service name>.<prefixed LDAP value> • principal key is a now derivative of the name of the group • assumes that names of the group will not change over time • permission rules can be added by back-end processes before the group is defined (because no abstract key assignment is needed) Information Technologies

  24. JIT LDAP – Scalability and Performance • At most one LDAP search per user • LDAP search time is < 50 milliseconds • User signs on (search LDAP if the user’s groups were not cached) • Real user groups: Search LDAP for the user’s groups • Logical user groups: get all ancestor groups using internal group hierarchy • Memory requirement: • A single instance of the group hierarchy (per LDAP attribute) • A cache that maps all signed on users to their groups Information Technologies

  25. JIT LDAP – Loose Ends • Key value: default node separator is dot, ‘.’ • group key = an LDAP attribute value • A group key cannot contain dot ‘.’ • JIT LDAP replaces all ‘.’ with ‘#’ • Change node separator (available in uPortal 2.1.5 or above) • For example, “->” Information Technologies

  26. JIT LDAP – Current Status • Using JIT LDAP since October 2003 • Primary staff and faculty portal • Users (3600+): Most groups are derived from LDAP • primary classifications (with 1000+ members) • other categories (with 500+ members) • Permissions specified using JIT LDAP groups • 500 sign-on’s per day (Sign on response time, 3 to 5 seconds) • Student portal in September 2004 Information Technologies

  27. JIT LDAP – What’s next? (1) Better Group/Permission Manager Integration • No pre-definition of groups required • Find “Group of Persons”: searches data store instead of cache • Tricky in LDAP: a list of groups/subgroups may not exist • Permission Manager: (group key = group name) • Maybe specify the principal by using an open input field instead of selection list? • Or, define a group name temporarily via group manager Information Technologies

  28. JIT LDAP – What’s next? (2) Permission Manager Convenience • Union operation – multiple “GRANT” rules • Negation operation – “DENY” rules (kind of) • Supports group definition using set operators: • union: has one of the given group names • intersection: has all given group names • difference: has one but not the other group name • negation: has none of the given group names Information Technologies

  29. JIT LDAP – What’s next? (3) Auto derivation of hierarchical relationship • Structured group names required, e.g., federated group names • English.101.L01.T02 triggers the creation of group hierarchies, like, • EnglishEnglish.101English.101.L01English.101.L01.T02 • EnglishEnglish.101 (suppress the rest) • English101L01T02 (portal group name = leaf component of the portal group key) Information Technologies

  30. JIT LDAP – What’s next? (4) Factor out JIT logic • Allows data store independent • Accepts user’s group names received during sign-on • JIT just caches the user’s group names • JIT re-queries sign-on server for group names if necessary (Note: We have a SSO server that can provide a user’s group names at sign-on time) Information Technologies

  31. Comparison to PAGS Comparison to PAGS Information Technologies

  32. Comparison to PAGS (1) Design Difference 1: Value as group key verses value as data • JIT LDAP: LDAP value is the key of the group • Value can be is AS IS • PAGS: LDAP value is a piece of personal data • Additional interpretation may be required Information Technologies

  33. Comparison to PAGS (2) Design Difference 2: Abstract key verses verbose key • JIT LDAP: Use the name of the group as the key • No internal key management • Permission rules are group name dependent • PAGS: Use an abstract key • Abstract key management • Group names can change without affecting permission rules Information Technologies

  34. Comparison to PAGS (3) • Just-In-Time verses Invariant • JIT LDAP: New groups are created as needed • PAGS: Groups are defined (created) at start up • Group Definition • JIT LDAP: Explicit exclusion - include all unless specified • PAGS: Explicit inclusion – include only if specified Information Technologies

  35. Comparison to PAGS (4) • External verses Internal Group Membership Definition • JIT LDAP: No “business” logic • External agents set up group membership • Logical groups are there for (permission manager) convenience only • PAGS: “business” logic defined via IPersonTester • Specifies group membership selection criteria (ad hoc) Information Technologies

  36. Comparison to PAGS (5) • Sub-group construction: bottom up verses top down • JIT LDAP: Bottom up • raw group loaded from LDAP • find all ancestors group from the internal hierarchy • PAGS: Top down • Recursive descends down hierarchy and tests Information Technologies

  37. Institutional Group (IG) Institutional Group Implementation Issues Information Technologies

  38. Institutional Group (IG) “Institutional” group characteristics: • Very large membership, lots of subgroups • Membership defined by complex business processes • Massive group definition/membership changes periodically Examples: • courses taken by a student • active teaching assistant Information Technologies

  39. IG - Implementation Issues Our considerations and re-considerations • Just-in time or invariant • Group name space management • Group relationship • Automatic group membership – time sensitivity • Source of a person’s group information: pull or push model • Stateful or stateless group information Information Technologies

  40. IG - Just-In-Time verses Invariant Why Just-In-Time? • Performance – load as needed instead of all at group expansion • Availability – better suits 24x7 operation • Manageability • Delegation of administration/definition to external agents • Single authoritative definition source • Dynamic – group information can be pulled from or pushed by any source Information Technologies

  41. IG - Group Name Space (1) How to resolve group name conflict: the same name can be used to mean different things • Existing name conflict resolution methods: • Abstract key/Double naming: internal name in place of LDAP value • For example: PAGS • Name prefixing: prefix LDAP value with the LDAP attribute name • For example: JIT LDAP Information Technologies

  42. IG - Group Name Space (2) • Better Solution: Structured/federated group name Examples: DNS names, java class packages, subsystem-A.application-B. ... • Our re-consideration: We are moving towards structured group names • Uses group names AS IS, no prefixing, no abstract key • Delegates the management of sub name space to applications • Maximizes reusability and sharing of group names amongst applications Information Technologies

  43. IG – Group Relationship (1) How to define group relationship Refer to a set of (related or unrelated) groups collectively during authorization specifications • Current method: • Each application defines its own, e.g, • JIT LDAP defines them as a hierarchical tree in its configuration These relationships are invisible among applications, not reusable. Information Technologies

  44. IG – Group Relationship (2) • Simple methods to increase the reusability of sub-group relationships: • Explicitly spell out in LDAP • Implicitly derived from the structured name Information Technologies

  45. IG – Group Relationship(3) Explicitly spell out: subgroup relationship is explicit, e.g, • LDAP values have these characteristics • a parent group always exists if one of its children group exists • e.g. ‘Faculty of Engineering’ exists if ‘Electrical Engineering’ exists • a child group may not exist even though its parent group exists • e.g ‘Faculty of Engineering’ can exist by itself Information Technologies

  46. IG – Group Relationship(4) Explicitly spell out: Pros/Cons: • (+) Relationship is available and shareable from LDAP • (+) Relationship can be ad hoc • (-) May duplicate a lot of data • (-) May be difficult to maintain data consistency Information Technologies

  47. IG - Group Relationship (5) Implicitly derived from structured group names • Examples: • English.101.L01.T02 • EnglishEnglish.101English.101.L01English.101.L01.T02 • W2004FREN101L01T02 • W2004FREN101L01->T02 Information Technologies

  48. IG – Group Relationship (5) Implicitly derived sub-group relationship: Pros/Cons • (+) No duplicate data • (+) No name conflict • (-) tends to be hierarchical relationship only • (-) group names may become verbose, e.g., “a.b.c.d” • (+/-) Relationship is “visible” and shareable but each application has to interpret the “same” way Information Technologies

  49. IG – Group Relationship (6) Re-consideration: • Original plan: • Use portal internal sub-group definition • Revised plan • Use structured names and explicitly spell out sub-group relationships Information Technologies

  50. IG – Time Sensitivity (1) When to add/drop group definition and membership massively • The role ceases but its function lingers • For example: Teaching assistant (TA) • Cease to be a TA at the end of term • Continue to perform some TA functions after the term ends, e.g., submit student grades etc • HR may not tread the person as TA but the faculty continues to do so Information Technologies

More Related