From f805247be236d58c7b5a197f08a5b3be8bb823eb Mon Sep 17 00:00:00 2001 From: Keith Hazelton Date: Wed, 17 Nov 2021 13:43:02 -0600 Subject: [PATCH] Create comanage-wb-registry.adoc --- comanage-wb-registry.adoc | 40 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 comanage-wb-registry.adoc diff --git a/comanage-wb-registry.adoc b/comanage-wb-registry.adoc new file mode 100644 index 0000000..37880a6 --- /dev/null +++ b/comanage-wb-registry.adoc @@ -0,0 +1,40 @@ +_2021-11-17 14:00 COmanage as Workbench Registry_ + +Tommy Doan zoom: + +- - - + +22 Oct SIWG: + +Assess what is involved in reconfiguring the CSP Workbench to use COmanage as Registry and midPoint for Provisioning (Tommy Doan, BennO, PaulC, ChrisHu) + +- Reroute source systems to COmanage from midPoint +- Have COmanage tell midPoint which systems to provision +- TommyD: Goal: Transition COmanage from a Guest SoR to the central person registry, to populate the Grouper subject source +- Paul: If mP does all the downstream provisioning, don’t need to reroute the source systems; Switch the identifier generation to COmanage; COm handles onboarding, etc. +- BennO: What’s the functionality we’re trying to establish? Are we wiring SOR to mP and have mP send stuff to COmanage, or COmanage sending SOR data to mP; If you have upstream SoRs (PS Banner) and multiple systems need the SoR data, do you create a unified IAM source stream/interface: Fork the flow from the interface; +- KeithL: What is the overall intent? What are we trying to gain? Is it an integration problem that COm is solving +- Tommy: Componentizing: Have registry do registry, and provisioner do provisioning; so consolidate SOR feeds into COmanage; +- ChrisHu: Have COmanage populate ou=people? WB sub source is LDAP; Do you want to use COm 4? BennO: 4; TommyD: We have COm 4 now +- TommyD: Have COm populate a db table; or have it populate an LDAP directory that’s used only for the IAM systems, not for user authN. Whichever that system is will act as the Grouper subject source and the midPoint identity source. +API and SQL provisioner; has its own data model, cleans out the metadata and creates a purer person table; +- KeithL: What are registry’s primary functions? Tommy: Id Match, identity generation/assignment, populate the Grouper subj source / midPoint person data; +- ChrisHu: Get a WB branch on 4.0 for use +ID Match 1.0 to be released in a week or two. Want Registry 4 with Match to make match configurable. Dump COm DB after the initial config, then re-import clean; BennO: It’s probably best for now +- Ethan: Lots of sleep and wait calls in our docker-compose.yml +- TommyD: What does mP need for person identities? PaulC: in mP, ‘name’ needs to be a persistent person identifier; +- KeithL: ‘name’ as username? Connecting to Banner use GUID or… +- Ethan: We use numeric, opaque, unchanging identifier (EMPLID) for use in Grouper Subject Source +- TommyD: Use same source as Grouper subj source and mP data source? +- ChrisHu: COmanage generated id is Gnnnnnnnn, carried as an SoRID in mP; mP generates its own via scriptable process, harder to work with than COm; mP uses groovy, COm identifier UI is quite flexible; +- KeithL: Something that ‘links’ vs ‘correlates’ accounts; +COm has account linking (multiple IdPs mapping to one COm person identity. + +. + +- - - +Want to meet to nail down some details of how you want to set up COmanage as the Registry for the Workbench? + +For example do you want to connect non-prod versions of your source systems to COmanage, or just use the mock HR and SIS delivered with the Workench? + +I’m pretty sure we could get help from some of the partners on this if they have experience in what you’re trying to do.