group namespaces

[Leif Johansson]

I'm fairly new to this group (although not to some of the work that is
tangential to SCIM - some of you know me from IETF and other places)
so forgive me if this has been raised before....

I have an application where groups have names that are part of managed
name spaces - mostly used for managing access control. As I started to
implement a SCIM server for this application it dawned on me (call me
stupid for not realizing this) that SCIM doesn't have any concept of
name space for any of its standard resources. I realize that it would
be fairly easy to define an extension schema for groups that define
'name_space' attribute but since all clients would have to implement
this extension in order to create groups (since name_spaces are the
basis for ACLs) in my implementation, chances for interoperability
would be somewhat limited.

Here are some questions...

- has name spaces for groups or any other type of resource been
discussed?
- is anyone else considering similar extensions?
- how is an extension schema documented - i.e what does rfc2252 look
like for SCIM?
- should I just give up and roll my own API?

Cheers Leif

[Morteza Ansari (moransar)]

Hi Leif,

Welcome to the group! I was hoping to catch up with you in Paris, but
the week went by so quickly.

In general the namespace is not defined as part of the SCIM spec itself
as there were two scenarios that were discussed. The first case is when
the namespace is global (giant single tenant) where a username is a
username and it must be unique globally. The other case was when
namespace is segmented and for that case (multi-tenant), the URL is the
qualifier to the namespace to make it globally unique.

I have not heard of anyone requesting extension for solving the
namespace. Though your use case might be a new one driving such
requirement. I would be interested to hear if the URL qualification
solves your use case.

How extensions are managed is pretty vague and is one of the reasons we
wanted to move this work to IETF to define better process around it.

And I will skip answering your last question ;-)

Cheers,
Morteza

[Leif Johansson]

On Apr 10, 11:59 pm, "Morteza Ansari (moransar)" <moran...@cisco.com>
wrote:

> Hi Leif,
>
> Welcome to the group!  I was hoping to catch up with you in Paris, but
> the week went by so quickly.
>

Quite

> In general the namespace is not defined as part of the SCIM spec itself
> as there were two scenarios that were discussed. The first case is when
> the namespace is global (giant single tenant) where a username is a
> username and it must be unique globally. The other case was when
> namespace is segmented and for that case (multi-tenant), the URL is the
> qualifier to the namespace to make it globally unique.
>

Ah so in that case you'd (say) POST to /Groups/a/nother/namespace/ to
create a group for instance? If so the spec isn't exactly clear on
that option...

> I have not heard of anyone requesting extension for solving the
> namespace. Though your use case might be a new one driving such
> requirement.  I would be interested to hear if the URL qualification
> solves your use case.

Using the URI would be preferred!

>
> How extensions are managed is pretty vague and is one of the reasons we
> wanted to move this work to IETF to define better process around it.
>

OK good then. We should talk about that some more. There are other
groups talking about a post-rfc2252 attribute language.

> And I will skip answering your last question ;-)

Excellent!

[Samuel Erdtman]

Not completely sure, but I think that Morteza means

POST /another/namespace/Groups

I.e. Namespace/Tenant comes before (in url) what is defined by the
SCIM 1.0 specification. This is defined as Base URL in section
http://www.simplecloud.info/specs/draft-scim-api-00.html#defs

//Samuel

[Leif Johansson]

On Apr 11, 10:00 am, Samuel Erdtman <sam...@erdtman.se> wrote:
> Not completely sure, but I think that Morteza means
>
> POST /another/namespace/Groups
>
> I.e. Namespace/Tenant comes before (in url) what is defined by the
> SCIM 1.0 specification. This is defined as Base URL in sectionhttp://www.simplecloud.info/specs/draft-scim-api-00.html#defs
>
> //Samuel
>
>
>

OK I guess that makes sense. This seems like something that needs to
be clarified in the spec :-)

[Kelly Grizzle]

Leif,

Have you seen the targeting proposal yet? I'm not sure if this would address your need, but multi-tenancy is was considered with targeting.

https://datatracker.ietf.org/doc/draft-hunt-scim-targeting/

--Kelly

[Morteza Ansari (moransar)]

Yes, what Samuel said :)

[Morteza Ansari (moransar)]

Do you think targeting addresses the namespace issue? I don't see how that works unless the schema at each endpoint is different which means the namespace would also be different, I guess.

[Kelly Grizzle]

Targeting would not address this unless the namespaces are different logical target applications. If the groups need to be namespaced within a single identity provider targeting would not help.

[Leif Johansson]

11 apr 2012 kl. 19:42 skrev "Morteza Ansari (moransar)" <mora...@cisco.com>:

> Do you think targeting addresses the namespace issue? I don't see how that works unless the schema at each endpoint is different which means the namespace would also be different, I guess.

It does not address the namespace issue - in fact it makes it worse.

[Morteza Ansari (moransar)]

Just out of interest, how does it make it worse? I don't like the
complexity it brings, but I don't see how it makes the namespace problem
worse.

Cheers,
Morteza

-----Original Message-----
From: cloud-d...@googlegroups.com
[mailto:cloud-d...@googlegroups.com] On Behalf Of Leif Johansson

Sent: Wednesday, April 11, 2012 10:29 PM
To: cloud-d...@googlegroups.com
Cc: <cloud-d...@googlegroups.com>
Subject: Re: group namespaces

[Leif Johansson]

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

On 04/12/2012 08:45 AM, Morteza Ansari (moransar) wrote:
> Just out of interest, how does it make it worse? I don't like the
> complexity it brings, but I don't see how it makes the namespace
> problem worse.

Because the Target spec currently doesn't leave any room in
the URI templates for namespaces (that I could see at least...)

Cheers Leif

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

iEYEARECAAYFAk+GvloACgkQ8Jx8FtbMZnfNjQCfUnf8We3nJaj/Pu7MQ7t+Fwdo
R5EAniuf5pq2QLNeNJhRVEPDk/1hyC7D
=R5VT
-----END PGP SIGNATURE-----