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 should 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.
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 direction 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 on Grouper side we used databases views: one for groups and one for group memberships. On Sun IdM side we used one single source resource adapter to get both - users and groups. Views are periodically polled by Active Sync, using timestamps in the views to get last changed identities.
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, krmítka, ...
Podrobnosti o resourcech na univerzitě?
??? věci kolem dvou typů skupin v LDAPech, o problémech, ale možná dát jen do grantu...
Papoušci
Základní koncept:
- trychtýř: pravidelné olizování zdrojových systémů (Stag, CRO), seznamy loginů berem z LDAPu (tam jsou i lidé mimo CRO)
- krmení koncových systémů (LDAP, 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
