Subject: [scim] Question about Filtering in SCIM Spec

From: Florian Wilhelm <[email-masked]>
Date: Wed, 19 Aug 2015 11:17:22 +0200

Hello,

I'm working on the osiam.org project, which implements SCIMv2. We have
an issue [1] in our project. I'm not quite sure if that is specified by
the SCIM spec.

Our user wants to filter
    not(groups eq "<groupId>")
[Expected result: All users that are not included in a given group]

and

    not(members eq "<userId>")
[Expected result: All groups in which is the user not a member]

Our current implementation does not deliver the expected results.
My question: Is this defined in the SCIM spec? I've read [2], but did
not find anything about that there.
If it is valid: What would be the expected result? What does not() on
groups or members mean?

Best regards,
Florian Wilhelm

[1] https://github.com/osiam/resource-server/issues/7
[2] https://tools.ietf.org/html/draft-ietf-scim-api-19#section-3.4.2.2

-- 
Florian Wilhelm
Software Development

tarent solutions GmbH Niederlassung Berlin
Voltastraße 5, D-13355 Berlin • http://www.tarent.de/
Tel: +49 30 138803-0 • Fax: +49 30 56829495

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg

---

From: Phil Hunt <[email-masked]>
Date: Wed, 19 Aug 2015 10:02:40 -0700

Florian…

You’ve managed to hit on a couple of oddities that go back to SCIM 1 (I think).

For the query against the Groups resource, try:

not(members.value eq “<userid>”)

“members” is a complex attribute and thus the comparison attribute is value.  Some SCIM systems may accept this, but it was never actually defined in the specs that “value” could be assumed to be the default comparison sub-attribute for a complex attribute. I just learned this myself a couple of weeks ago.  :-)

Regarding querying against members (of the User resource):
Because the specification indicates the “members” attribute mutability is “readOnly” many implementations will only calculate its contents when returning the user resource and thus members is likely not indexed. 

Phil

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

> On Aug 19, 2015, at 2:17 AM, Florian Wilhelm <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Florian Wilhelm <[email-masked]>
Date: Mon, 24 Aug 2015 17:46:15 +0200

Hello Phil,

thank you for your reply. It seems as if I could not make my question
clear enough.

We are trying to implement the SCIM spec and are not clear on what it
says about this specific case.

Quote from Page 22, first paragraph,
https://tools.ietf.org/html/draft-ietf-scim-api-19#page-22
> the filter matches if any of the values of the specified attribute
match the specified criterion

Definition of the "not" operator,
https://tools.ietf.org/html/draft-ietf-scim-api-19#page-19:
> The filter is a match if the expression evaluates to false.

To what "match" from section 3 does the "not" apply?

Case 1:

The "not" is related to the first "match", so 'not (expression)' means:
"the filter matches if not any (= none) of the values of the specified
attribute match the specified criterion".

Case 2:

The "not" is related to the second "match", so 'not (expression)' means:
"the filter matches if any of the values of the specified attribute
don't match the specified criterion".

To illustrate my question, please consider the following example:

User 1
Groups: A, B, C

User 2
Groups: B

User 3
Groups: A, C

When I query "Group eq 'B'", the result is User 1 and User 2, which is
perfectly fine and conforms to the spec.

But when I query "not(Group eq 'B')", what should be the actual the result?

Case 1: "the filter matches if not any (= none) of the values of the
specified attribute match the specified criterion"

The result would be only User 3, because all others have an attribute
that contains "B".

Case 2: "the filter matches if any of the values of the specified
attribute don't match the specified criterion"

The result would be User 1 and User 3, because each of them has at least
one attribute that doesn't contain "B". Compare this with the following
table, that shows the data in some kind of relational structure:

User | Group | eq | not(eq)
-----+-------+----+--------
  1  |   A   | -  |  +
  1  |   B   | +  |  -
  1  |   C   | -  |  +
  2  |   B   | +  |  -
  3  |   A   | -  |  +
  3  |   C   | -  |  +

* User 1 matches, because it has at least on "+" in the last column
* User 2 doesn't match, because all values in the last column are "-"
* User 3 matches again, because it has at least on "+" in the last column

My question is: What is the correct interpretation of the "not" operator
in the context of a multi-valued attribute according to the spec?

Best regards,
Florian Wilhelm

-- 
Florian Wilhelm
Softwareentwicklung

---

From: Phil Hunt <[email-masked]>
Date: Mon, 24 Aug 2015 08:59:54 -0700

User 3. 

In this respect, the behavior would be similar to ldap and multi values. 

Phil

> On Aug 24, 2015, at 08:46, Florian Wilhelm <[email-masked]> wrote:
> 
> Hello Phil,
>

---

From: Thomas Krille <[email-masked]>
Date: Tue, 25 Aug 2015 10:53:48 +0200

Hello Phil,

I assume, that this is also true for all other comparison operators and all
other multi-valued attributes?

Regards

Thomas Krille

2015-08-24 17:59 GMT+02:00 Phil Hunt <[email-masked]>:

> >> “members” is a complex attribute and thus the comparison attribute is
> value.  Some SCIM systems may accept this, but it was never actually
> defined in the specs that “value” could be assumed to be the default
> comparison sub-attribute for a complex attribute. I just learned this
> myself a couple of weeks ago.  :-)
> >>
> >> Because the specification indicates the “members” attribute mutability
> is “readOnly” many implementations will only calculate its contents when
> returning the user resource and thus members is likely not indexed.
> >>
> >> Phil
> >>
> >> @independentid
> >> www.independentid.com
> >> [email-masked]
> >>

-- 
Thomas Krille
Softwareentwicklung
tarent solutions GmbH

Telefon +49 (0) 30 555785-128
Telefax +49 (0) 228 54881-235
[email-masked]

Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-0 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
Steeg

---

From: Phil Hunt <[email-masked]>
Date: Tue, 25 Aug 2015 04:02:01 -0700

If the attrib is indexed, yes. 

Phil

> On Aug 25, 2015, at 01:53, Thomas Krille <[email-masked]> wrote:
> 
> Hello Phil,
> 
> I assume, that this is also true for all other comparison operators and all other multi-valued attributes?
> 
> Regards
> 
> Thomas Krille
> 
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg