Re: [scim] Question about Filtering in SCIM Spec

[Phil Hunt <[e-mail]>]

If the attrib is indexed, yes. 

Phil

> On Aug 25, 2015, at 01:53, Thomas Krille <[e-mail]> wrote:
> 
> 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 <[e-mail]>:
>> 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 <[e-mail]> wrote:
>> >
>> > 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
>> >
>> >
>> >> Am 19.08.2015 um 19:02 schrieb Phil Hunt:
>> >> 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
>> >> [e-mail]
>> >>
>> >>> On Aug 19, 2015, at 2:17 AM, Florian Wilhelm <[e-mail]> wrote:
>> >>>
>> >>> 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: [phone] • Fax: [phone]
>> >>>
>> >>> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
>> >>> Tel: [phone] • Fax: [phone]
>> >>> HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
>> >>> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
>> >>> Steeg
>> >>>
>> >>> _______________________________________________
>> >>> scim mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/scim
>> >
>> > --
>> > Florian Wilhelm
>> > Softwareentwicklung
>> >
>> > tarent solutions GmbH Niederlassung Berlin
>> > Voltastraße 5, D-13355 Berlin • http://www.tarent.de/
>> > Tel: [phone] • Fax: [phone]
>> >
>> > Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
>> > Tel: [phone] • Fax: [phone]
>> > HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
>> > Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander
>> > Steeg
>> 
>> _______________________________________________
>> scim mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/scim
> 
> 
> 
> -- 
> Thomas Krille
> Softwareentwicklung
> tarent solutions GmbH
> 
> Telefon [phone]
> Telefax [phone]
> [e-mail]
> 
> Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
> Tel: [phone] • Fax: [phone]
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
> _______________________________________________
> scim mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scim