[scim] AuthZ proposal for SCIM
Travis Spencer <tspencer@pingidentity.com> Fri, 25 May 2012 09:02 UTC
Return-Path: <tspencer@pingidentity.com>
X-Original-To: scim@ietfa.amsl.com
Delivered-To: scim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3E21F862A for <scim@ietfa.amsl.com>; Fri, 25 May 2012 02:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.976
X-Spam-Level:
X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnABMNIIpW2d for <scim@ietfa.amsl.com>; Fri, 25 May 2012 02:02:34 -0700 (PDT)
Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id 40AEB21F861F for <scim@ietf.org>; Fri, 25 May 2012 02:02:30 -0700 (PDT)
Received: from mail-lb0-f171.google.com ([209.85.217.171]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKT79KpcBBCuWuXRAwLDR878QesgNnfwX5@postini.com; Fri, 25 May 2012 02:02:30 PDT
Received: by lbom4 with SMTP id m4so1166404lbo.16 for <scim@ietf.org>; Fri, 25 May 2012 02:02:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=wqmjVnczt/zlFXkqnHP1d6PyeQ6ZFnxGxMDNIGX1u5w=; b=Z7nuFi/EZmVmgFEa00mumtFsVFLT1x+WjUgE4r0LjWe3C7suiNjhDWDJECg+JNW8iw ujRyNjGhmQHcqLo1UJyNl8YVYdjVjKdzqSHverB7N7Q1vHDhD3dcHL4aQcQWdpm1CxA+ Tz5Vlf2JcZF9znQ+//JQiHgiy1DbKNoPQ9sWmM4VLRnCfSnCpbmGPnekH5b3/2gTZww6 osSew1ayBn4m5VVYKlbjmxxk3PaWZVtBQseIgly7eS/RqlyQA0sq93ez/LM59+uJoNqt qL2L48nqkaCTUd2yxt2ZHPbG2sk7xWtRa4iog6hXrg4Wkq22aoE4z1AnioQH2DASzUS8 1M0A==
Received: by 10.152.145.41 with SMTP id sr9mr2708039lab.25.1337936547709; Fri, 25 May 2012 02:02:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.36.194 with HTTP; Fri, 25 May 2012 02:01:57 -0700 (PDT)
From: Travis Spencer <tspencer@pingidentity.com>
Date: Fri, 25 May 2012 11:01:57 +0200
Message-ID: <CABOwN+xospBxMv35EuXHrLpXHHtQfmK+HrROMW2zqC7UpcNvoQ@mail.gmail.com>
To: scim@ietf.org
Content-Type: multipart/alternative; boundary="bcaec5396502a8818904c0d8a0ed"
X-Gm-Message-State: ALoCoQnf4LTaTTRBCab2mVqfa7V095hIOIDdXEwef7NKaIWoFbS5uPf5hRIs6e3zeNPnDsdmftv6
Subject: [scim] AuthZ proposal for SCIM
X-BeenThere: scim@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Simple Cloud Identity Management BOF <scim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/scim>, <mailto:scim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/scim>
List-Post: <mailto:scim@ietf.org>
List-Help: <mailto:scim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/scim>, <mailto:scim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 May 2012 09:02:37 -0000
Hi All, Please find below a proposal for changing how entitlements are handled in SCIM. This proposal is based on various discussions that have been happening in the community, so hopefully there is agreement on the general idea. If there are objections or details that need to be worked out, I welcome the feedback. To be added to .well-known, SP Config, or whatever we end up w/ in the long-run (i.e., section 9 of the draft): The following multi-valued attribute is defined in addition to the common attributes defined in Core Schema: entitlementSchemes A complex type that specifies supported Entitlement Scheme properties. Instead of the standard Canonical Value for type, this attribute defines the following Canonical Values to represent common schemes: none and basic. REQUIRED. name The common Entitlement Scheme name; e.g., XACML. REQUIRED. description A description of the Entitlement Scheme. REQUIRED. specUrl An HTTP addressable URL pointing to the Entitlement Scheme's specification. OPTIONAL. documentationUrl An HTTP addressable URL pointing to the Entitlement Scheme's usage documentation. OPTIONAL. When basic is supported, a service provider MUST also support the following single value attribute which defines the entitlements that it supports. basicEntitlements A list of string values that represent the entitlements that the service provider supports. REQUIRED if the basic Entitlement Scheme is supported. To replace entitlements in section 6.2 of the core schema doc: entitlements A complex attribute containing the entitlements of a User. Entitlements are the rights that a User has at the Service Provider as expressed according to the policy language stipulated by the type sub-attribute. A basic syntax is defined in this specification that allows the Client to specify a list of entitlements as strings. There are NO canonical values specified, but a Client can learn what values are supported by requesting the Service Provider Configuration Resource and examining the list found in the basicEntitlements attribute. type A string indicating the type of policy language. The only acceptable canonical value is basic. REQUIRED. If the type of policy is not understood, the Service Provider MUST return an HTTP 400, bad request. value The entitlements of the user. If the type is basic, this MUST be a list of strings where the elements are from the list of supported entitlements defined in the Service Provider's basicEntitlements schema attribute. If the type is NOT basic, then the value MUST be a complex object that the Service Provider is expected to know how to process. If the complex object cannot be processed according to the syntax of the policy language specified in the type attribute, the Service Provider MUST return an HTTP 400, bad request. A non-normative examples of using the basic Entitlement Scheme is as follows: { "entitlements" : { "type": "basic", "value" : [ "calendar", "email", "spreadsheet" ] } } Service Providers MAY support additional policy languages instead of or in addition to the basic one define herein. For example, a Service Provider may support XACML and the Client may send the entitlements of a User in accordance to that specification as in the following non-normative example: { "entitlements" : { "type" : "xacml", "value" : { /* XACML policy encoded in JavaScript */ } } } -- Regards, * * *Travis Spencer, BSCS, MBA* | Sr. Technical Architect, CTO Office *Ping* *Identity* | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *M:* +46 72 725 5655 *Email:* tspencer@pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Connect with Ping* Twitter: @pingidentity <http://twitter.com/pingidentity> LinkedIn: Ping's Identity Cloud<http://www.linkedin.com/groups/Ping-Identity-Cloud-2603712> Facebook: Ping Identity Page <https://www.facebook.com/pingidentitypage> *Connect with me* Twitter: @travisspencer <http://twitter.com/travisspencer> LinkedIn: travisspencer <http://linkedin.com/in/travisspencer>
- [scim] AuthZ proposal for SCIM Travis Spencer
- Re: [scim] AuthZ proposal for SCIM Phil Hunt
- Re: [scim] AuthZ proposal for SCIM Igor Faynberg
- Re: [scim] AuthZ proposal for SCIM Samuel Erdtman
- Re: [scim] AuthZ proposal for SCIM Radovan Semancik
- Re: [scim] AuthZ proposal for SCIM Chris Phillips
- Re: [scim] AuthZ proposal for SCIM Travis Spencer
- Re: [scim] AuthZ proposal for SCIM Travis Spencer
- Re: [scim] AuthZ proposal for SCIM Igor Faynberg
- Re: [scim] AuthZ proposal for SCIM Anthony Nadalin
- Re: [scim] AuthZ proposal for SCIM Igor Faynberg