LPS:Grouper/Canc
Java System Sun Identity Manager (Sun IdM)
There is deployed Sun Java System Identity Manager (IdM) of at University of West Bohemia. Groups and memberships shall be managed by Grouper.
Data synchronization
There are several synchronization methods in Sun IdM. The two most important are Reconciliation and Active Sync.
Reconciliation: it's used for basic comparing of the data in identity management and on target resource. Synchronization goes through all identities, so most usual way is using it just for examination missing identities and performing basic responses (create, delete, unlink, ...). Checking attributes changes are possible, but quite exhaustive.
Active Sync: it's important for on-line updates. There is expected to update only identities changed on the source resource, so this synchronization type is usually used for transfer changed attributes too. Using this method requires support on the source resource - possibility to select all identities changed from the last processed synchronization.
Support for groups
IdM has some basic support for managing groups on several types of the target resources. For example directory based (LDAP, Active Directory) and unix-like resources have manageable group members via multivalue attribute of the user identity. Group memberships on resource are managed by updating this attribute.
Groups itself and their metadata are represented as special type of resource objects on target resources in Sun IdM. Creating, updating and deleting groups itself is not supported in Sun IdM as is, but it's possible by own custom workflows. More simplistic approach could treat groups the same way, as user identities, using two separated resources - one for users and other for groups. We chose the more difficult and more interesting way - using custom workflows and treat groups as special identities.
University of West Bohemia environment
The distributed computing environment at the university has central administration. All passwords are stored in Kerberos system, authorization in web applications (WebAuth, SSO) is using groups in LDAP or static lists.
The systems with groups at University of West Bohemia are:
- LDAP "rfc2307" - unix accounts and groups, used for autorization too
- LDAP "portal" - identities for portal
- AFS - pts groups and users
- Windows Active Directory - domain control for Windows world
LDAP directory
Two duplicated balanced OpenLDAP servers. There are two branches ("rfc2307" and "portal"), in both there are identities with reverse information about memberships too (group list for each account).
Unix group numbers
In addition we have two group types in main LDAP directory branch:
- posixGroup - with gid number
- pleiadesGroup - without gid number
Sun IdM resource adapter was extended to support our additional schema pleiadesGroup.
Custom workflow can change the schema when needed, by recreating the group.
Grouper deployment with Sun IdM
At University of West Bohemia we keep dynamic groups up to date via our import tools, synchronizing data in Grouper directly from source agendas.
Our goal on the Sun IdM side was the unidirectional way, from Grouper to Sun IdM, where Sun IdM will take care of all various target resources at university.
Synchronize groups between Grouper and Sun IdM
When we will take into account removing groups too, managing users AND groups may lead to race conditions. For Sun IdM we needed to avoid to assign users to non-existing groups on target resources. Solution we chose was the adjusted order of the updates:
- process all changed (or created) existing groups
- process all users with changed memberships
- process all groups for delete
As interface for Sun IdM on the Grouper side we used databases views: one for groups and one for group memberships. Views are periodically polled by Active Sync, using timestamps in the views to get last changed identities.
On Sun IdM side we used one single source resource adapter to get both - users and groups:
| column | value | |
|---|---|---|
| users | groups | |
| accountId | login name | group internal identifier ('group.'STEM:GROUP_NAME) |
| objectClass | 'user' | 'group' |
| grpgroups | membership group names (multivalue) | group name |
| grpenabled | membership group states (multivalue) | group state |
| grpchanged | time of the membership group changes (multivalue) | time of the group metadata change |
| grpgid | - | group unix id number |
| grpstem | - | group stem in Grouper |
As seen from the table: removing groups are not deleted from the views. Just marked as disabled, with the proper timestamp in grpchanged.
Sun IdM configuration files
cvs -d:local:/afs/zcu.cz/project/software/cvsroot co -d . project/idm/danaus/objects
- Resources/grouper.xml - configuration of the resource adapter
- Resources/actions/grouper-*.xml - resource actions in Java (using JDBC API)
- ZCU ActiveSync Grouper Handle Group.xml - group synchronization custom workflow
- and other objects (metaview.xml, ZCU Rules.xml, ...)
Grouper interface
- více o databázovém interface - dva pohledy: skupiny, členství - přítomnost v pohledech řízena oprávněním (IDM)
- možná se prolíná s dalšími věcmi: použití vlastností postgress databáze na zjednodušení a zkulturnění kódu Grouperu, krmítko (=importer), cucátko (=feeder)...
Realization
Basic concept:
- "filler": regular checkout from source systems (Stag - study agenda, CRO - person registry), list of logins in LDAP directory
- Sun IdM: updating end systems (LDAPs, Active Directory, AFS, ...)
Původní Grouper
Načítání do Grouperu bylo velmi neefektivní, v řádu hodin (!) (C6, S2), a koncové systémy byly udržované "zašpagetovanými" skripty cronem (G1, G2).
TODO: na obrázku by měl tady Grouper taky nasosávat z LDAPu
Tedy:
- C6, S2 - koncepčně v pořádku, ale velmi pomalé
- G1, G2 - potřeba odstranit a nahradit Identity Managementem
Nový Grouper
Optimalizovaný trychtýř (přenost dat do Grouperu za minutu), informace z Grouperu pouze jedním kanálem do IdM, to pak udržuje ostatní systémy jednotným způsobem (v rámci napojení I4, I5), snadno jdou přidávat další koncové systémy (I2 - AFS nemáme, ale víme jak na to, I13 - Active Directory ověřeno, jen jsme nedali během hromadných registrací do provozu).
Tedy:
- G1, G2, G2 - optimalizovaný trychtýř
- I4, I5 (v plánu I13, I14) - krásně a koncepčně přes centrální identity management
