Skip to content
Permalink
main
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

iam-knowledge-bits/docs/comanage-wb-registry.adoc

Go to file
 
 
Cannot retrieve contributors at this time
79 lines (47 sloc) 4.35 KB
Raw Blame
Open in GitHub Desktop

2021-11-17 14:00 COmanage as Workbench Registry

Tommy Doan, Ethan Kromhout, Keith Hazelton zoom:

midPoint provisioning back to COm: COm sets emailAlias, passes to mP;

but maybe mP should get the email from the email service and write the email back to COm; similar to phone number;

COm will be primary place Help Desk looks for user info, so good to have emails and phone numbers there.

COmanage will mint an email alias; users might want a different one, mark one as primary, or mark another as inactive

integrate WB SIS and HR with COmanage as Registry

COm populates a table with all CO persons; to present the data to Grouper, we’ll need a view that can serve as a subject source, and a source for mP

make aliases visible to

UNC favors API, or messaging; (religious distaste for direct access to tables or views or LDAP)

API contracts are better; Messaging, too; (SMU: for PS Integration Broker) EK: Person Basic sync would be better than UNCs customized IB messages

TommyD guiding principles: 1) treat as modular as possible so any one of them can be replaced. 2) if we had table or views, seems to simplify the integration

TD is doing PS to COm EK is doing PS to mP for now Campus Solutions is effectively their Registry, want to move to mP; Grouper manages roles, and maps to PS privs.

TD: wants to produce per integration point diagrams; He’d need WB to process PS IB messages; High Priority: Develop the COmanage view that Grouper uses as a subject source.; Have mP leverage same view into source tables; Then WB becomes really interesting as another way to look at the TAP suite as a whole.

Grouper subj source: Identifiers, name, dept? description?? EK: Ripe for review at UNC since it’s tricky to find the desired subject when LDAP has millions

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

  • 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

  • - -

git clone -b COmanageAsRegistry git@github.internet2.edu:internet2/InCommonTAP-Examples.git

  • 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.