Subject: [scim] Aliases and perm resource URLs - is redirect a solution?

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Dec 2013 11:43:06 -0800

I had a casual conversation by email with Kelly and Erik, it seems useful to have this discussion with the wider group.

Issue:  There is a desire by a lot of developers to support easy URLs, supposedly to avoid lookups.  These URLs can be of the form:

1.  To reference the current "subject" in the current security context:
GET https://<some_domain>/<some_prefix>/v2/Users/me

2.  To reference a user by their user id (MS OData and Google Directory do forms of this):
GET https://<some_domain>/<some_prefix>/v2/Users/<user_id>

Note that for item 2, it could *easily* be re-expressed as:
GET https://<some_domain>/<some_prefix>/v2/Users?filter=username eq <user_id>

The catch comes when you want to use those aliases for other operations.  Eg. update telephone number for the current user.

PATCH https://<some_domain>/<some_prefix>/v2/Users/me

The big concern is we want clients to be using the permenant URL which is of the form:
PATCH https://<some_domain>/<some_prefix>/v2/Users/<guid>
This is the form that must be used for group membership or any reference to the item.

A. Support Alias Using Redirects
It occurs to me that we *might* be able to use redirects.  This causes another request response.  But in practice it is not as costly as one might think. In practice it is done within the same HTTP connection and this is almost as fast (in the same way that browsers re-use connections to load hundreds of graphic images etc).

Reading 2616, and searching on stackoverflow, etc, it seems that a 301 "permanent" redirect fits.  This allows the "alias" to be used, but at the same time, it always informs the client that the permanent URL is the one that will not change.  In contrast, 302, suggests that the client should use the alias since the redirected URL may change in the future.

The catch is that RFC2616's 3xx introduction states:
The action
   required MAY be carried out by the user agent without interaction
   with the user if and only if the method used in the second request is
   GET or HEAD. A client SHOULD detect infinite redirection loops, since
   such loops generate network traffic for each redirection.

In our case we want to *preserve* the action as is. A PATCH should not convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE redirect (unless something else needs to be considered due to proxies and gateways).

The alternatives?

B. Aliases Transparently Accepted
Service Providers could simply accept the request as is and process directly. When they return a record, the Location value should always be the perm URL rather than the alias.   The downside to this, is the tendency to get lazy and use non-perm URLs that may change (particularly those using a user-id).

C. Aliases Not Supported
All operations must be based on immutable perm URLs.  This may often require the clients to remember perm URLs (or obtain them through the access token, etc).  Or the client apps must do a query before modify step.  This isn't that unusual.  This happened in LDAP all the time.  However, in LDAP this lead to a lot of desire to hard code predictive DNs creating a lot of incompatibility (I made a lot of money fixing these issues).   For many it would mean pressure to use record identifiers based on a login id rather than a guid.

I don't really have a particular strong position on any of these. But I do think we need to include in the api document a clarification on "redirects" one way or the other. If we leave this unspecified, you could see clients having to deal with a wide variety of interpretation here.  

I do see some positives in supporting aliases if only because major providers like MS, Facebook, and Google are already doing it.  It might be useful for them to share the postives/negatives of their experience if possible. Does this lead to problems with multiple ways to reference objects?

Everyone's input appreciated. I'll volunteer to assemble any comments back into a ticket next week.

Phil

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

---

From: Patrick Radtke <[email-masked]>
Date: Thu, 05 Dec 2013 14:19:29 -0800

I'm curious about the potential for naming conflicts for using

https://<some_domain>/<some_prefix>/v2/Users/<user_id>

For example, we have a valid user with the username 'me', which would be 
problematic if 'me' is keyword to reference the current subject of the 
security context.
Similarly, we've had users choose names that looked like random 
gibberish, which would have a very unlikely chance of conflicting with 
the service provider generated id if we allowed this style of aliasing.

LinkedIn's style may be less prone to conflicts.

https://<some_domain>/<some_prefix>/v2/Users/~
would be used to get the current subject

and

https://<some_domain>/<some_prefix>/v2/Users/username=bob

would load a specific user (without the extra ListResponse data that 
comes with doing filtering.)

I think it would be desirable to have a way to determine the permanent 
URL for the subject of the current security context even if the group 
decides not to support aliases.

I don't have a preference amongst the proposed solutions.

-Patrick

On 12/5/13, 11:43 AM, Phil Hunt wrote:
> I had a casual conversation by email with Kelly and Erik, it seems
> useful to have this discussion with the wider group.
>
> Issue:  There is a desire by a lot of developers to support easy URLs,
> supposedly to avoid lookups.  These URLs can be of the form:
>
> The catch comes when you want to use those aliases for other operations.
>   Eg. update telephone number for the current user.
>
> It occurs to me that we *might* be able to use redirects.  This causes
> another request response.  But in practice it is not as costly as one
> might think. In practice it is done within the same HTTP connection and
> this is almost as fast (in the same way that browsers re-use connections
> to load hundreds of graphic images etc).
>
> Reading 2616, and searching on stackoverflow, etc, it seems that a 301
> "permanent" redirect fits.  This allows the "alias" to be used, but at
> the same time, it always informs the client that the permanent URL is
> the one that will not change.  In contrast, 302, suggests that the
> client should use the alias since the redirected URL may change in the
> future.
>
> In our case we want to *preserve* the action as is. A PATCH should not
> convert to GET, etc. Also, clients SHOULD NOT tolerate more than ONE
> redirect (unless something else needs to be considered due to proxies
> and gateways).
>
> The alternatives?
>
> Service Providers could simply accept the request as is and process
> directly. When they return a record, the Location value should always be
> the perm URL rather than the alias.   The downside to this, is the
> tendency to get lazy and use non-perm URLs that may change (particularly
> those using a user-id).
>
> C. Aliases Not Supported
> All operations must be based on immutable perm URLs.  This may often
> require the clients to remember perm URLs (or obtain them through the
> access token, etc).  Or the client apps must do a query before modify
> step.  This isn't that unusual.  This happened in LDAP all the time.
>   However, in LDAP this lead to a lot of desire to hard code predictive
> DNs creating a lot of incompatibility (I made a lot of money fixing
> these issues).   For many it would mean pressure to use record
> identifiers based on a login id rather than a guid.
>
> I don't really have a particular strong position on any of these. But I
> do think we need to include in the api document a clarification on
> "redirects" one way or the other. If we leave this unspecified, you
> could see clients having to deal with a wide variety of interpretation
> here.
>
> I do see some positives in supporting aliases if only because major
> providers like MS, Facebook, and Google are already doing it.  It might
> be useful for them to share the postives/negatives of their experience
> if possible. Does this lead to problems with multiple ways to reference
> objects?
>
> www.independentid.com <http://www.independentid.com>
> [email-masked] <mailto:[email-masked]>
>
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 5 Dec 2013 15:45:44 -0800

The stipulation would be the alias' must resolve uniquely - such as in the case of user id. 

Phil

> On Dec 5, 2013, at 14:19, Patrick Radtke <[email-masked]> wrote:
> 
> For example, we have a valid user with the username 'me', which would be problematic if 'me' is keyword to reference the current subject of the security context.
> Similarly, we've had users choose names that looked like random gibberish, which would have a very unlikely chance of conflicting with the service provider generated id if we allowed this style of aliasing.
> 
> would load a specific user (without the extra ListResponse data that comes with doing filtering.)
> 
> 
> I think it would be desirable to have a way to determine the permanent URL for the subject of the current security context even if the group decides not to support aliases.
>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Fri, 6 Dec 2013 08:26:44 +0000

Speaking as an implementer not as chair:

In our implementation we have added the notion of "/users/me" and it seems pretty useful. It does not cause a conflict in our implementation as our "id" namespace has a very specific format and it is not possible to have a "me" as an id.

We do not support the second case and I would worry about supporting such alias given consumer could start caching that and a change in userName could result in invalid link or worse end up pointing to the wrong entry.  Using 301 redirect is an interesting notion but as Phil suggested it won't address some of the cases.  I am also interested in hearing from other implementers on their experience with implementing aliases.

Cheers,
Morteza

From: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 5, 2013 11:43 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scim] Aliases and perm resource URLs - is redirect a solution?

The action

The alternatives?

C. Aliases Not Supported

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Tue, 10 Dec 2013 09:27:51 -0800

FWIW, I just found the following draft which defines 307 (temporary redirect) and 308 (perm redirect).
http://tools.ietf.org/html/draft-reschke-http-status-308-07

These new HTTP 307 and 308 responses mirror 302 and 301 except that they require the operation to be preserved.  In contrast, 302 and 301 require that the HTTP verb be changed to GET or HEAD.

It occurs to me that in addition to support for aliases, the 307 temporary redirect may be useful for re-directign clients to a failover node or other proxy.

In terms of 308, when applied to "/me" or "/Users/<somealias>" the 308 redirect to where the real operation should be performed.

A 308 might also be used against "/Users/<resource-id>" when a resource has moved, changed tenancies, or been assigned a new id (not sure why, but seems reasonable).

As for whether a service provider supports a particular alias, I think that will be quickly evident to clients since they will not get redirects but rather NOT FOUND responses.  It seems reasonable that SPs could choose to implement aliases based on almost any unique key they choose. It might be reasonable to expect that typically this is just a user-id as the issue seems to be one of coordination with other security components in the system (e.g. having to map the currently authenticated subject to a SCIM resource).

Phil

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

On 2013-12-06, at 12:26 AM, Morteza Ansari (moransar) <[email-masked]> wrote:

> From: Phil Hunt <[email-masked]>
> To: "[email-masked]" <[email-masked]>