Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] SCIM support for Grouper?

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] SCIM support for Grouper?

Chronological Thread 
  • From: Tom Barton <>
  • To:
  • Subject: Re: [grouper-users] SCIM support for Grouper?
  • Date: Mon, 18 Mar 2013 17:06:11 -0500
  • Authentication-results:; dkim=neutral (message not signed) header.i=none

Hi Niels,

As I think you know we try to prioritize our work in alignment with community needs. In particular, we've tried to add new capabilities in concert with a partner that shows up with a real use case and resources to commit to help us be sure that we build something that actually works for their use case. We are currently partnering with CMU to iron out some performance issues with PSP, also providing the newest member of our development team with a great opportunity to get familiar with its internals. One approach is to engage with you on SCIM as the CMU engagement winds down. Do you have an idea of the time frame within which you might be able to partner with us on this?


On 3/18/2013 11:36 AM, Niels van Dijk wrote:

I was wondering if Grouper roadmap has SCIM on it.

We have a use case where we are using SCIM to provision group info to a
cloud provisioning broker who then provisions various other clouds
services via none-standard APIs. Until now this was mostly test cases
(SCIM functionality outside of Grouper), now we would like to look at
doing this for 'real'.
As our groups already live in Grouper, and Grouper already has
capabilities e.g. to determine the difference between group memberships
between date A and date B, this seems like a good fit, I think.

I note that last years I2 Spring Meeting had some discussions [1] and in
2011 a MACE-Dir discussion [2] addressed a lot of issues that by now
have been solved I think. Neither however have a clear direction for
SCIM in regards to Grouper.

If it is on the roadmap, are there any timeliness? If not, what ways
would there be to accelerate this? We have coding capabilities, but
coding an entire new API out of the blue is probably not a good idea ;)

Any thoughts?



Archive powered by MHonArc 2.6.16.

Top of Page