You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »


Wiki Home

Grouper Release Announcements

Grouper Guides

Grouper Deployment Guide

Community Contributions

Internal Developer Resources

This is a suggestion for how user data could flow to Grouper in future state

The problem this is trying to solve

  • User data in subjects, provisioners, and loaders solve similar problems
  • Real time data solved in multiple ways
  • Security of who is allowed to see what
  • Efficiency of being able to query data without reaching out to other resources
  • Ability to use data from multiple sources at one time
  • Reduce the number of network calls in various places
  • Reduce the SQL and LDAP syncs required to make things work

Setup entity resolvers

The first configuration step is to set up entity resolvers

For users

  • SQL queries
  • LDAP filters
  • WS calls

Returns

  • Single valued attributes for users
  • Returns multi-valued attributes for users
  • Multivalued rows of attributes for users (e.g. affiliation rows that have affiliation and dept)


Grouper gets that data

  • Copies to Grouper database
  • Could process the data a tad
  • "Virtual attributes" can have logic and make a complicated description attribute (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 attribute could have a group assigned who can see the data
  • There are real time events or timestamps that ensures data is up to date


Subject source

    • Points to Grouper's database
      • Instead being configured against source would be configured against entity resolver data
      • Can use data from multiple sources
    • Note, if entity resolver data is secure and available over UI/WS then the subject doesnt need as many fields... e.g. Penn would not need first name and last name etc.  
    • Subject could just be id
    • People who are allowed to see various entity resolver attributes would see description a certain way, name a certain way, and whatever attributes they can see when they need it
    • Imagine a more detailed subject page for people who can see the data... easier to troubleshoot access

Members table

  • Members table can be stripped down since data is in the entity tables

Loaders

  • Loaders and jexl scripted groups can be written on top of entity data
  • Non admins can securely use that data since Grouper knows who is allowed to see what
  • When the entity resolver knows that data changed real-time, it knows which loader/jexl scripted group to update
  • Not all data about users will be entity resolvers... more than what was in subject source, but not everything
  • If there is peripheral data you can make SQL/LDAP loaders for that

UI/WS

  • Imagine more attributes than subject attributes available over WS/UI securely in one query

Provisioning

  • No more "subject link"
  • You can provision any entity resolver data easily
  • When data changes, Grouper can tell a provisioner to recalc a user

Summary

In summary here is a metaphor... we used to have SQL credentials in multiple places, then we made an external system layer to re-use that.  This suggested is similar.  Have a data layer that can we re-used across things.  Includes real-time updates, security, and data manipulation configured centrally...  why?  if we want to be ABAC and attribute-based, we need to organize our attributes

  • No labels