Subject: [scim] SCIM and Cloud-based Directory Services

From: Bjorn Aannestad <[email-masked]>
Date: Thu, 08 Nov 2012 08:36:20 -0600

I'll be giving a short talk next week introducing "SCIM and Cloud-based 
Directory Services".   (The Ping event in Ft.Worth/Dallas).    To 
encourage further adoption of SCIM, I'd like to cite the momentum it 
already has.

If you have or know of a SCIM implementation effort that extends SCIM 
beyond provisioning, please let me know.    All I need is the company 
name/project name, though I'd be very interested in further 
conversations here at IETF or later.

UnboundID has one, and I am aware of Phil Hunt's draft directory spec.

Thanks!
-Bjorn Aannestad

-- 
__________________________________________________________
Bjorn Aannestad | Dir, Product Management | UnboundID Corp
mailto:[email-masked] | 512-769-6461

---

From: Emmanuel Dreux <[email-masked]>
Date: Thu, 8 Nov 2012 22:19:02 +0000

We have merged SCIM into a WEBID implementation to provide authentication without password.
We presented it last week at the W3C TPAC who took place in Lyon with the presence of Tim Berners Lee in the room.

We have used the open source project https://my-profile.eu/ which has a builtin webid profile server implementation and added automatic provisioning of webid profiles through SCIM (Active Directory to webid synchronization).

For that, we had to create a brand new SCIM schema.
The first deployment is planned beginning of January for a SAAS partner who provides virtual desktops for BYOD scenarios. Target: about 15 000 students.
We'll be able to communicate about it in the beginning of 2013.

Additional note:
The interesting thing in this project is that we imagined exchanging data directly in RDF instead of JSON or XML.
(And you could/would argue that it's not SCIM anymore).

I remember a thread this week about removing XML and adding vcard support.
-1 for this.
If you want a technological breakthrough, integrate native rdf support, and this will open IAM platforms to semantic intelligence, with native storage of identities as RDF graphs.

--
Cordialement / Regards,
Emmanuel Dreux
http://www.cloudiway.com
Tel: +33 4 26 78 17 58
Mobile: +33 6 47 81 26 70
skype: Emmanuel.Dreux

-----Message d'origine-----
De : Bjorn Aannestad [mailto:[email-masked]] 
Envoyé : jeudi 8 novembre 2012 15:36
À : scim WG
Objet : [scim] SCIM and Cloud-based Directory Services

Thanks!
-Bjorn Aannestad

---

From: Bjorn Aannestad <[email-masked]>
Date: Fri, 09 Nov 2012 15:04:30 -0600

Thank you, Emmanuel, that is this helpful!

-Bjorn

---

From: Phil Hunt <[email-masked]>
Date: Fri, 9 Nov 2012 13:15:52 -0800

I would very much prefer keeping authn out of scim. I don't want to imply or limit possibilities for authn support. Keep it to other layers. 

Phil

On 2012-11-09, at 13:04, Bjorn Aannestad <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Melinda Shore <[email-masked]>
Date: Fri, 09 Nov 2012 12:21:34 -0900

On 11/9/2012 12:15 PM, Phil Hunt wrote:
> I would very much prefer keeping authn out of scim. I don't want to
> imply or limit possibilities for authn support. Keep it to other
> layers.

I don't think that's possible, since it can lead to interoperability
problems and has potentially serious consequences (do you
really want to allow an unauthenticated entity to provision
identities?).  At a minimum it will need to be discussed in the
security considerations section.

Melinda

---

From: Bjorn Aannestad <[email-masked]>
Date: Fri, 09 Nov 2012 15:28:45 -0600

Two points:
1. This thread started as a request by me to surface SCIM-as-directory 
projects
2. I think the SCIM docs already cover the stance with respect to 
authN.  However, if we want to discuss that, let's start a different thread.

-Bjorn

---

From: Melinda Shore <[email-masked]>
Date: Fri, 09 Nov 2012 12:46:13 -0900

> authN.  However, if we want to discuss that, let's start a different

Here's what's in the API draft:

   "The SCIM protocol does not define a scheme for authentication and
   authorization therefore implementers are free to choose mechanisms
   appropriate to their use cases."

That is definitely going to need to be revisited at some point in the
not-too-distant future, but it doesn't need to be discussed today.

Melinda

---

From: Phil Hunt <[email-masked]>
Date: Fri, 9 Nov 2012 15:11:31 -0800

I agree there may be need for further clarification in both the core API draft and the directory drafts on authentication.

The phrase quoted below (specifically  "SCIM protocol"), is incorrect. Unlike LDAP, SCIM is not a TCP/IP protocol. SCIM is a RESTful service that runs on HTTP protocol.  

So while LDAP needed to have an authentication method (bind), HTTP already has one. SCIM defining one is redundant and represents a lot of potential complexity.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Fri, 09 Nov 2012 14:14:03 -0900

On 11/9/2012 2:11 PM, Phil Hunt wrote:
> So while LDAP needed to have an authentication method (bind), HTTP
> already has one. SCIM defining one is redundant and represents a lot
> of potential complexity.

Right, not to mention the considerable possibility of getting
it wrong.  I don't think that anybody was suggesting that the
SCIM working group cook up a new authentication protocol, at
least I hope not.  But what needs to be done is to define/
describe/profile the use of an existing authentication
mechanism.

Melinda

---

From: Hasini Gunasinghe <[email-masked]>
Date: Sat, 10 Nov 2012 05:33:00 +0530

Hi Bjorn,

WSO2 Identity Server <http://wso2.com/products/identity-server/> supports
SCIM in its 4.0.0 release, based on WSO2 Charon which implements the SCIM
specification under Apache 2.0 license.

You can find more info about the supported use cases etc at:
http://hasini-gunasinghe.blogspot.com/search/label/SCIM

Thanks,
Hasini.

On Thu, Nov 8, 2012 at 8:06 PM, Bjorn Aannestad <
[email-masked]> wrote:

> Directory Services".   (The Ping event in Ft.Worth/Dallas).    To encourage
> further adoption of SCIM, I'd like to cite the momentum it already has.
>
> name/project name, though I'd be very interested in further conversations
> here at IETF or later.
>
> ______________________________**____________________________