More Than a Robust and Scalable LDAP Group

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

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

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

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 4

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

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 6

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 7

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 8

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 9

JIT LDAP - Basics u. Portal 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 10

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

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

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

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

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 15

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

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 17

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 18

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 19

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

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 21

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 22

JIT LDAP - Permission Manager Implication Permission manager: permission grant/deny by 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 23

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 24

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 u. Portal 2. 1. 5 or above) For example, “->” Information Technologies 25

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 26

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 27

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 28

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

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 30

Comparison to PAGS Information Technologies 31

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 32

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 33

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 34

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 IPerson. Tester 1. Specifies group membership selection criteria (ad hoc) Information Technologies 35

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 36

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

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 38

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 39

IG - Just-In-Time verses Invariant Why Just-In-Time? Performance – load as needed instead of all at group expansion Availability – better suits 24 x 7 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 40

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 41

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 42

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 43

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 44

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 45

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 46

IG - Group Relationship (5) Implicitly derived from structured group names Examples: English. 101. L 01. T 02 English. 101. L 01. T 02 W 2004 FREN 101 L 01 T 02 W 2004 FREN 101 L 01 ->T 02 Information Technologies 47

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 48

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 49

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 50

IG – Time Sensitivity (2) Individual relinquishes a role but (s)he needs access to data created when (s)he was in that role for example, payroll information for ex-TA Not so good solution: print all such information Some re-thinking about applications is required Information Technologies 51

IG – Group Information Source (1) Original Plan: use LDAP Open standard – well supported, use a “pull” model Let participating applications have access to all person’s info LDAP administrative password distribution and management Re-consideration: a “push” model a central server “pushes” out a person’s group information no password distribution required person’s information can be filtered Information Technologies 52

IG – Group Information Source (2) Re-consideration: Our SSO server is already providing the data - Although proprietary, participating applications has to understand the SSO server anyway. - Derived (Logical) sub-groups can be defined and shared among applications. (LDAP contains only “raw data”. ) How about Shibboleth? Is SAML sufficient? Information Technologies 53

IG – Stateful or stateless Original Plan: pull model using LDAP “Stateless” because each application retrieves its group info. Group info. inconsistency across applications because of application internal caches Re-consideration: a “push” model “Stateful”, applications received info. from the SSO server Our SSO server can demarcate when a session begins and ends Group info consistency across applications Information Technologies 54

Identity Amalgamation (IA) Identity Amalgamation Information Technologies 55

Identity Amalgamation (IA) One person owns multiple LDAP entries one primary identity, multiple service account identities multiple primary identities due to special/historical requirement, e. g. , student ID, staff ID Ideally, an identity should be converted to become a role. In real life, this might not be possible. Information Technologies 56

IA – Linking LDAP entries A simple solution: linking identities (LDAP entries) using a cross-reference (XRef) LDAP attribute Look up roles of any LDAP entry that has the same XRef value Merge resultant roles from the look up Important: Do not assume that a person must have an unique LDAP entry Information Technologies 57

IA – JIT LDAP sample solution <config> <url>ldap: //ldap. univerity: 389/ou=people, o=some. university</url> <bind. DN>cn=manager, ou=people, o=some. univesity</bind. DN> <bind. Password>manager-password</bind. Password> <keyfield>xref</keyfield> LDAP filter: xref=${key} <keyvalue>${key}</keyvalue> <retention-time>180</retention-time> </config> Information Technologies 58

IA – Implication All services belonging to the person (not identity) are presented A service has to determine which identity should be use if a person has multiple identities. Information Technologies 59

End of Presentation Information Technologies