[Issue 93] Making member attribute optional in group

[Hasini Gunasinghe]

Hi all,

There is a issue[1] reported to make member attribute optional in group.

Quoting from the issue:

"Many servers do not require members when a group is created, and many clients would like to create groups without members.  This attribute should be optional."

I too agree with the above since only LDAP backed user stores mandate non empty member attribute when creating a group. (If the service provider has a LDAP backed user store and can not create a group without a member, it can return a 500 error with appropriate description)

However, wanted to check with the list before resolving the issue as the issue description suggests.

Is there any objections to remove the REQUIRED key word from the member attribute description of SCIM Group schema at [2] ?

[1] http://code.google.com/p/scim/issues/detail?id=93&q=Milestone%3DRelease1.1

[2] http://www.simplecloud.info/specs/draft-scim-core-schema-00.html#group-resource

Thanks,

Hasini.

[Erik Wahlström]

Sounds good to me.

/ Erik

[Morteza Ansari (moransar)]

Given your description, it would imply that LDAP backed stores will NOT be compliant with the spec. If the spec says members attribute is optional, then any compliant server MUST be able to create empty groups.

 

I don’t have a very strong objection to this, but I think it will make LDAP interoperability much more difficult.

 

 

Cheers,

Morteza

[Hasini Gunasinghe]

Hi Morteza,

On Wed, May 23, 2012 at 11:35 PM, Morteza Ansari (moransar) <mora...@cisco.com> wrote:

Given your description, it would imply that LDAP backed stores will NOT be compliant with the spec. If the spec says members attribute is optional, then any compliant server MUST be able to create empty groups.

 

I don’t have a very strong objection to this, but I think it will make LDAP interoperability much more difficult.

 

I agree that you have a valid point.

Above issue has been created as per a discussion related to IIW interop event - where it was discussed that member attribute needs not to be mandatory unless the underlying user store is LDAP.

So, to be in favor of both the arguments, I propose that we include this in Service Provider Configuration Schema.

In fact this is a configuration information of Service Provider, depending on whether it has a user store which mandates member attribute or not.

In that case, we can omit mentioning REQUIRED key word in member attribute description of Group schema and mention that it is required or not depending on the Service Provider Configuration information.

What do you think?

Thanks,

Hasini.

[Leif Johansson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/23/2012 08:05 PM, Morteza Ansari (moransar) wrote:
> Given your description, it would imply that LDAP backed stores will
> NOT be compliant with the spec. If the spec says members attribute
> is optional, then any compliant server MUST be able to create empty
> groups.
>
>
>

> I don?t have a very strong objection to this, but I think it will

> make LDAP interoperability much more difficult.
>

Yeah but its also one of the "DOH-moments" in LDAP. Not sure we want
to preserve it. Also the way to handle this in the backend is "just"
to add and remove the group (or groupOfUniqueNames) objectClass as
the last member goes away. Of course you have to keep track of what
is "supposed to be a group" but that is doable.

Cheers Leif

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/DXD4ACgkQ8Jx8FtbMZnfIaACgpfCKxcNm8SkjDJn7j7UXFzMK
chYAnRYI98Wjzm66CJaf46ZqqHC/LdDi
=6pfi
-----END PGP SIGNATURE-----

[Kelly Grizzle]

I agree that this is a legacy that we don't want to preserve.


> [Hasini] I propose that we include this in Service Provider Configuration Schema.

My vote would be to make it optional in the core schema and use the "required" attribute in the /Schemas resource to specify whether the service provider requires this or not.

--Kelly

[Trey Drake]

+1 you beat me to it.

Thanks,
Trey

[Hasini Gunasinghe]

+1 for this approach.
Thanks all for coming to a conclusion on this issue.

Hasini.

[Morteza Ansari (moransar)]

Schema discovery solves the problem, but put the burden on the client developer to deal with the additional complexity. I am fine with the change, but wanted to be clear about the tradeoff that we are making here.

 

 

Cheers,

Morteza

[Hasini Gunasinghe]

Hi,

Following is the proposed changes in the text of scim-core-schema spec to address this issue: Removed word and newly added sentence are marked with underlines in both versions respectively. Please raise if there is any concern with it....

Old:

A list of members of the Group. Canonical Types "User" and "Group" are READ-ONLY. The value must be the "id" of a SCIM resource, either a User, or a Group. The intention of the Group type is to allow the Service Provider to support nested Groups. REQUIRED

New:

A list of members of the Group. Canonical Types "User" and "Group" are READ-ONLY. The value must be the "id" of a SCIM resource, either a User, or a Group. The intention of the Group type is to allow the Service Provider to support nested Groups. It MAY require to provide a non-empty members value based on the "required" sub attribute of the "members" attribute in Group Resource Schema as defined by the Service Provider.

Thanks,

Hasini.

[Kelly Grizzle]

This looks good.  I would reword it slightly to make it more clear.  Something like:

 

Service Providers MAY require Consumers to provide a non-empty members value based on the "required" sub attribute of the "members" attribute in Group Resource Schema.

 

--Kelly

[Hasini Gunasinghe]

+1. Added the modified proposed text to the issue.

Thanks,

Hasini.