Subject: [scim] SCIM Schema specification correction and question

From: Steve Moyer <[email-masked]>
Date: Tue, 21 Apr 2015 16:02:31 -0400

Though it's been a while since I've sent anything to the list, we've
been successfully using SCIM 2.0 (with a few differences) since January
of 2014.  We're looking at bring our installation up to the current
specification and so I'm revisiting the documents (draft 17).  I'll
write a case-study for anyone who's interested - a short description is
an OpenLDAP/Fortress-backed system with 2.6M user accounts.

Our original components were built from the specifications using first
principles and continuing that trend, I've created an object to
represent the JSON Schemas (per section 3 and 7 of the SCIM Schema
specification), converted the three schemas (in section 8.7.1 of the
SCIM Schema specification) to individual JSON objects and then used a
JSON parser/mapper to attempt to read the JSON schemas into the Schema
object.

Reading the User Schema in this way results in an error in
User.groups.value as there's a "readOnly" attribute that I believe has
been obsoleted by the "mutability" attribute.  The User.groups.$ref,
User.groups.display and User.groups.type sub-attributes have the same
problem.  Removing the four instances of the "readOnly" attribute allows
the User schema to be parsed according to section 2 of the SCIM Schema
specification.

For completeness, here are the steps used to convert the published JSON
to individual JSON files for the User, Group and EnterpriseUser schemas:

1)  Copy the text from the SCIM Schema specification.
2)  Delete the page breaks included in the RFC.
3)  Split the document into three parts.
4)  Eliminate line feeds in all "description" attributes.
5)  Delete the "readOnly" attributes (User schema only).

I also have a question that I believe should be pretty easy to answer -
section 3.1 states:

      With the exception of "ServiceProviderConfig" and
      "ResourceType" server discovery endpoints and their associated
      resources, these attributes MUST be included in all resources,
      including any extended resource types.

I don't think the "externalId" attribute is applicable to the Schema
resource type ... when would this be used?

I should also note that it's unlikely our system will ever be completely
SCIM compliant ... our use cases generally revolve around keeping the
university's systems synchronized, so there are many clients of our SCIM
system.  While our SCIM Service Provider doesn't assign the externalId
(there is one external system that is allowed to create this value), our
server does enforce uniqueness on this field since only one user in the
SCIM system should be allowed with an associated externalId.

Finally, I'd like to thank everyone for their efforts in creating these
specifications, we've been mostly watching (so far) but will contribute
most of our SCIM code back to the community via the Apache Directory
project once the appropriate arrangements are made.  We'll also provide
at least one pass of proof-reading on draft 17 of the specification
documents.

All the best,

Steve Moyer

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 Apr 2015 15:01:40 -0700

Steve,

Thanks for the feed back. Good luck with your implementation. 

There are those of us that feel that SCIM on top of LDAP cannot be compliant. This is in part at least why we dropped the scim ldap mapping. The chief problem being LDAPs lack of complex attribute support. All mappings end up imposing changes on LDAP clients or compliance issues in SCIM. 

A few years ago I also proposed a scim directory with ldap legacy support. The difference being the underlying data store must support complex data.  Data that legacy clients often don't understand or care about. 

Phil

> On Apr 21, 2015, at 13:02, Steve Moyer <[email-masked]> wrote:
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Tue, 21 Apr 2015 15:01:40 -0700

Steve,

Phil

---

From: Steve Moyer <[email-masked]>
Date: Tue, 21 Apr 2015 19:40:36 -0400

Phil,

It's true that LDAP doesn't support but it's also true that LDAP is
still the default choice for user directories ... we're tired of writing
security into individual applications since it always ends up looking
something like this:

   User ------------------------> Roles ----> Permissions
           \                  /
             ----> Groups ----

This explains why we're adopting ANSI RBAC (Fortress) for our entire
security model and standardizing on how these elements are stored and
accessed.

I followed your LDAP mapping and even had a couple discussions with you
almost 18 months ago ... I believe we've found a solution that, while
it's not as elegant as I'd like (a pure mapping solution) is working for
2.6M users and is accessed tens to hundreds of thousands of times per
day.  I remember you warning against LDAP attribute options (and
especially their affect on legacy clients) but we've found a mapping
that works.

If the SCIM filter wasn't ambiguous in the same way LDAP filters are, I
think we'd have also had a hard time with the searching ... specifically
on the address complex type.  Fortunately these filters are broadly
compatible:

    (&(streetAddress=123 Elm Street)(postalCode=54321))

equals:

filter=streetAddress%20eq%20%22123%20Elm%20Street%22&postalCode%20eq%20%2254321%22

The one place our system becomes problematic is actually for LDAPv3
clients ... there are situations where the client will have to
de-duplicate the multi-valued attributes.  It also mean our SCIM Service
Provider does much more than match entries during searches and map
attributes back and forth.  We will however fail to be completely SCIM
compliant since our schema is slightly different than the one published
with the specification (e.g. clients can't write userName, uniqueness is
enforced server-side on externalId, etc).

We'd previously promised the Apache Directory team that I'd publish our
"mapping" (which in some cases is a straight map and in other cases is
an algorithm) and we'd be happy to share it with this group as well. 
Perhaps you'll find other holes in our implementation and can help move
the entire group forward.

Thanks again for all the help and advice ... you've obviously put a ton
of time into making this specification successful!

Steve

-- 
"One longs, in reading your code, to walk on all fours" - Voltaire

---

From: Steve Moyer <[email-masked]>
Date: Tue, 21 Apr 2015 20:17:43 -0400

***** Correction *****

The LDAP filter in my previous e-mail should have been:

      (&(street=123 Elm Street)(postalCode=54321))

Sorry for any confusion!

Steve

On 04/21/2015 07:40 PM, Steve Moyer wrote:
> still the default choice for user directories ... we're tired of
> writing security into individual applications since it always ends up
> looking something like this:
>
> I followed your LDAP mapping and even had a couple discussions with
> you almost 18 months ago ... I believe we've found a solution that,
> while it's not as elegant as I'd like (a pure mapping solution) is
> working for 2.6M users and is accessed tens to hundreds of thousands
> of times per day.  I remember you warning against LDAP attribute
> options (and especially their affect on legacy clients) but we've
> found a mapping that works.
>
> If the SCIM filter wasn't ambiguous in the same way LDAP filters are,
> I think we'd have also had a hard time with the searching ...
> specifically on the address complex type.  Fortunately these filters
> are broadly compatible:
>
> de-duplicate the multi-valued attributes.  It also mean our SCIM
> Service Provider does much more than match entries during searches and
> map attributes back and forth.  We will however fail to be completely
> SCIM compliant since our schema is slightly different than the one
> published with the specification (e.g. clients can't write userName,
> uniqueness is enforced server-side on externalId, etc).
>
> We'd previously promised the Apache Directory team that I'd publish
> our "mapping" (which in some cases is a straight map and in other
> cases is an algorithm) and we'd be happy to share it with this group
> as well.  Perhaps you'll find other holes in our implementation and
> can help move the entire group forward.
>
> Thanks again for all the help and advice ... you've obviously put a
> ton of time into making this specification successful!
>
> Steve