[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>