Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes

From: Kelly Grizzle <[email-masked]>
Date: Wed, 16 Oct 2013 21:20:28 +0000

Does anyone have any problems with defaulting the Group.members attribute as being returned by default?  Any objections to closing this ticket with the change suggested in ticket #10?

--Kelly

-----Original Message-----
From: scim issue tracker [mailto:[email-masked]] 
Sent: Wednesday, October 02, 2013 10:35 AM
To: [email-masked]; Kelly Grizzle
Cc: [email-masked]
Subject: Re: [scim] #2: Add pagination capability to plural Resource attributes

#2: Add pagination capability to plural Resource attributes

Comment (by [email-masked]):

 General consensus so far has been that paginating on plural resource  attributes would over-complicate things.  The worry about large groups  could be alleviated by implementing a suggested change in ticket #10 where  each schema attribute can designate when it is returned:

 "returned"="always"|"never"|"default"|"request"

 For backwards compatibility, I suggest that Group.members remains as  "default", but SP's can optionally change this to "request" if it is  problematic.

-- 
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |       Owner:  [email-masked]
  [email-masked]|      Status:  new
     Type:  enhancement  |   Milestone:
 Priority:  major        |     Version:
Component:  api          |  Resolution:
 Severity:  -            |
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/scim/trac/ticket/2#comment:1>
scim <http://tools.ietf.org/scim/>

---

From: Thorsten Roßner <[email-masked]>
Date: Thu, 17 Oct 2013 09:08:04 +0200

The "returned" option seems to me very reasonable and a good solution to
avoid collecting all complex attributes on a standard request of the the
Users resource, while we should stay with all the fields (that are
returned today) in the default setting.

Though I would like to understand in this context the "index" option
when it comes to that password field (as mentioned in ticket #47). Is it
intended by SCIM to have something like an "authenticate user" function
by performing a

GET /Users?filter=id eq "someID" AND password eq "somePassword"

request?

The index option - without digging into details - seems to
overcomplicate things and could cause interop problems.

Thorsten

---

From: Phil Hunt <[email-masked]>
Date: Thu, 17 Oct 2013 09:50:22 -0700

Regarding password.  No it wouldn't make sense for SCIM to have an authentication function. HTTP already has these mechanisms.  Authentication should involve much more than simple value match for an attribute.  For example most HTTP servers have some sort of access policy which intercepts requests and forces authentication.  Once authenticated, a session context is established.  That context should already be available to the SCIM service.

You may be thinking of LDAP which is analogous to HTTP.  (IOW  LDAP is not working at the same level as a REST service).

My feeling is that passwords should probably be treated as write-only (the actual value is stored as a hash).  I think it is reasonable to permit a exact match compare operation which is more likely used for password management (e.g. values in a possible passwordHistory set of values).  It could be used as a "poor-man's" authenticator, but in general my feeling is this is a bad practice.

It may also be reasonable for an access management to be able to call the SCIM service provider in a privileged way to be able to confirm password matches using a GET as you suggest below. Rather then SCIM providing an authentication "function", SCIM simply acts as an identity data provider (not unlike a SQL database).  The difference is that the client is making the authentication decisions, not the SCIM SP.  The authentication system may also use SCIM to check other items like login attempts and other things, not to mention comparing other authentication factors.   That said, all of this is currently out of scope -- though I'm open to working on proposing some standard schema here.

Phil

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

On 2013-10-17, at 12:08 AM, Thorsten Roßner <[email-masked]> wrote:

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

---

From: Thorsten Roßner <[email-masked]>
Date: Fri, 18 Oct 2013 09:38:43 +0200

Am 17.10.2013 18:50, schrieb Phil Hunt:
> Regarding password.  No it wouldn't make sense for SCIM to have an authentication function. 
I agree.
> My feeling is that passwords should probably be treated as write-only (the actual value is stored as a hash).  I think it is reasonable to permit a exact match compare operation which is more likel…
I also agree.

I see the need that we add the explicit information that the password
attribute can only be searched with the "eq" parameter to the Draft.

I'm still not in favor of having a generic "index" option on each field.

> It may also be reasonable for an access management to be able to call the SCIM service provider in a privileged way to be able to confirm password matches using a GET as you suggest below. 
But this priviledged way would be against SCIM specification as of today
(password: "This value MUST never be returned by a Service Provider in
any form.")?

Thorsten