...
- Copies to Grouper database
- Could process the data a tad
- "Virtual data fields" can have logic and make a complicated description data field (across multiple resolver sources)
- Its possible that this could help the problem of having too many subject sources though this isn't intended to be an identity system
- Can assign security so Grouper knows who is allowed to read which data
- Each data field could have a group assigned who can see the data
- There are real time events or timestamps that ensures data is up to date
- Each attribute should only come from one resolver
- Active flag will signify if the user can be added to Grouper groups / privileges (i.e. "resolvable")
Subject source
- Points to Grouper's database
- Instead being configured against sources would be configured against entity resolver data
- Can use data from multiple sources
- All identifiers must be unique
- Note, if entity resolver data is secure and available over UI/WS then the subject doesnt need any fields... e.g. Penn would not need first name and last name etc in the subject configuration.
- Subject is really just a collection of prioritized identifiers (e.g. employeeId is highest priority) and attributes
- People who are allowed to see various entity resolver data fields would see description a certain way, name a certain way, and whatever data fields they can see when they need it
- Imagine a more detailed subject page for people who can see the data... easier to troubleshoot access
- If an employee ID does change (and no other conflicts), the user could be resolved by other identifiers and it might "just work"
...