Grouper Developers Forum

[Chris Hyzer <>]

Ø  Why not add an additional LDAP for storing external users? For ldap many provisioning stuff already exists.

 

I added a note to the document that the storage should be pluggable, then it can use ldap

 

 

Ø  As a suggestion to Phase2 'invites with group provisioning': the ability to upload a CSV containing the people to be invited. This is convenient if you need to add 10+ people.

 

I put a note that multiple emails should be able to be entered at once

Ø  Also, we had a people picker, but decided that it was a better idea, from privacy viewpoint , that a person should be invited via his/her email address only. This way there has to be some 'out of band' mechanism for the inviter to get these adresses, and also the chance of being invited to a group by accident e.g.by  selecting the wrong person from the list is much smaller.

 

I think most people will want to use it like that.  Tom mentioned entering id’s since the admin might know the id…  hmmm

Ø  If you still want a people picker after the above point ;) I would suggest displaying both the name of the users as well as the institution, as many John Doe's may exist

Yes, the deployer should have a descriptive description of the subject

 

 

 

 

Ø  - One thing that seems required is the ability to have globally unique grouper instances. Also the 'source' of the group needs to be somehow expressed towards the application consuming the group relation, otherwise it cannot distinguish between 'admin'  of uniA and admin at uniB

 

Not exactly sure what you mean here, but I would assume only certain subject sources will be synced, and I would assume in the other institution the “external subjects” will need to exist or be synced as well.  I added that to the doc.

Ø  - The current proposal suggests the actual provisioning of user(s) and groups from grouperA -> grouperB. Keeping stuff in sync this way is tricky. Is it also possible to just query remote servers, so the process of linking group severs could be 'live'? The WS API of grouper would be able to do this nicely I think?

We discussed that on the paccman call today.  It seems the future is in the real time access… if the concern is things are not in sync, then I think the incremental provisioning should handle it.  It should take a few minutes to process, but changes will propagate…  anyways, dynamic groups have been mentioned before, and this seems like a good place to use them, so we will keep considering this.  I added a proxy note on the doc about this.

Thanks!

Chris