Skip to main content

[identity-api-spec users] [jsr351-experts] Re: some fragments from the SCIM schema

  • From: Werner Keil <werner.keil@...>
  • To: jsr351-experts@...
  • Subject: [identity-api-spec users] [jsr351-experts] Re: some fragments from the SCIM schema
  • Date: Thu, 23 Jan 2014 13:57:15 -0800
  • List-id: <jsr351-experts.identity-api-spec.java.net>

Ron/all,

JBoss just released Alpha 1 of Keycloak, see
http://bill.burkecentral.com/2014/01/23/keycloak-sso-released-alpha-1/

As you can see on the project page, it facilitates JSON Web Token (JWT)
also in discussion by IETF:
https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
Would you say that is of interest for JSR-351, too?

Werner

* Social Media Week Copenhagen: 17 Feb 2014, Copenhagen, Denmark. Werner
Keil, Eclipse JCP EC Member, JSR 354 EG Member, Agorava Cofounder will
present "Bitcoin, Payment Instrument or Object of Speculation?",
"Enterprise 2.0 with Agorava"

* Social Media Week Hamburg: 18 Feb 2014, Hamburg, Germany. Werner Keil,
Eclipse JCP EC Member, JSR 354 EG Member, Agorava Cofounder will
present "Bitcoin,
Payment Instrument or Object of Speculation?", "Enterprise 2.0 with Agorava"


On Tue, Jan 21, 2014 at 10:45 AM, Ron Monzillo <ron.monzillo@...>wrote:

>  Experts,
>
> In today's call, We will discuss the use of scim/json objects and jsr 351 
> attribute repository initialization.
> the following captures some of the basic definitions in SCIM. you can also 
> follow the link to the SCIM document.
>
> Ron
>
> -----
> Below, I've extracted some of the basic elements of the SCIM schema from 
> the following document.
>
> Schema for SCIM attributes copied from 
> http://datatracker.ietf.org/doc/draft-ietf-scim-core-schema/?include_text=1
> Mortimore, et al.        Expires March 03, 2014                 [Page 
> 6]Internet-Draft          draft-scim-core-schema-02            August 2013
>
> ------
> The 3 parts shown below, are
> 1. the attribute data types (sections 3.1 and 3.1)
> 2. the attribute schema (section 11)
> 3. the core user schema (section 6)
> --------
>  3.1.  Attribute Data Types
>
>    Attribute data types are derived from JSON [2] and unless otherwise
>    specified are optional, modifiable by Consumers, and of type String
>    (Section 3.1.1).  The JSON format defines a limited set of data
>    types, hence, where appropriate, alternate JSON representations
>    derived from XML schema [3] are defined below.  SCIM extensions
>    SHOULD not introduce new data types.
> 3.1.1.  String
>
>    A sequence of zero or more Unicode characters.  The JSON format is
>    defined in section 2.5 [4] of RFC 4627.  A String attribute MAY
>    specify a required data format.  Additionally, when Canonical Values
>    are specified Service Providers SHOULD conform to those values if
>    appropriate, but MAY provide alternate String values to represent
>    additional values.
> 3.1.2.  Boolean
>
>    The literal "true" or "false".  The JSON format is defined in section
>    2.1 [5] of RFC 4627.
> 3.1.3.  Decimal
>
>    A real number with at least one digit to the left and right of the
>    period.  The JSON format is defined in section 2.4 [6] of RFC 4627.
> 3.1.4.  Integer
>
>    A Decimal number with no fractional digits.  The JSON format is
>    defined in section 2.4 [7] of RFC 4627 with the additional constraint
>    that the value MUST NOT contain fractionial or exponent parts.3.1.5.  
> DateTime
>
>    A DateTime value (e.g. 2008-01-23T04:56:22Z).  The attribute value
>    MUST be encoded as a valid xsd:dateTime as specified in section 3.2.7
>    [8] of the XML Schema Datatypes Specification.
>
>    Values represented in JSON MUST conform to the XML constraints above
>    and are represented as a JSON String [9].
> 3.1.6.  Binary
>
>    Arbitrary binary data.  The attribute value MUST be encoded as a
>    valid xsd:base64Binary as specified in section 3.2.16 [10] of the XML
>    Schema Datatypes Specification.
>
>    Values represented in JSON MUST conform to the XML constraints above
>    and are represented as a JSON String [11].
> 3.1.7.  Reference
>
>    A reference to a SCIM Resource.  The value MUST be the absolute or
>    relative URI of the target Resource.  Relative URIs should be
>    resolved as specified in section 5.2 [12] of RFC 3986.  The base URI
>    for relative URI resolution MUST include all URI components and path
>    segments up to but not including the Endpoint URI; e.g., the base URI
>    for a request to https://example.com/v1/Users/2819c223-7f76-453a-
>    919d-413861904646 would be https://example.com/v1/ and the relative
>    URI for this Resource would be Users/2819c223-7f76-453a-
>    919d-413861904646.
>
>    Performing a GET operation on a reference URI MUST return the target
>    Resource or an appropriate HTTP response code.  The Service Provider
>    MAY optionally choose to enforce referential integrity for
>    references.
>
>    By convention, a reference is commonly represented as a "$ref" sub-
>    attribute in complex or multi-valued attributes, however this is
>    OPTIONAL.
> 3.1.8.  Complex
>
>    A Singular or Multi-valued Attribute whose value is a composition of
>    one or more Simple Attributes.  The JSON format is defined in section
>    2.2 [13] of RFC 4627.
> 3.2.  Multi-valued Attributes
>    Multi-valued attributes are unordered lists of attributes.  Each
>    attribute MAY contain Sub-Attributes and therefore multi-valued
>    attributes may contain Complex Attributes.  The below Sub-Attributes
>    are considered normative and when specified SHOULD be used as
>    defined.
>
>    type  A label indicating the attribute's function; e.g., "work" or
>       "home".
>
>    primary  A Boolean value indicating the 'primary' or preferred
>       attribute value for this attribute, e.g. the preferred mailing
>       address or primary e-mail address.  The primary attribute value
>       'true' MUST appear no more than once.
>
>    display  A human readable name, primarily used for display purposes.
>       READ-ONLY.
>
>    operation  The operation to perform on the multi-valued attribute
>       during a PATCH request.  The only valid value is "delete", which
>       signifies that this instance should be removed from the Resource.
>
>    value  The attribute's significant value; e.g., the e-mail address,
>       phone number, etc.  Attributes that define a "value" sub-attribute
>       MAY be alternately represented as a collection of primitive types.
>       For example:
>
>       <snip>
>
>    $ref  The Reference of the target Resource, if the attribute is a
>       reference.
>
>       <snip>
> -------------
>
> 11.  Schema Schema
>
>    The Schema schema specifies the Attribute(s) and meta-data that
>    constitute a Schema.  Schema Resources are READ-ONLY and identified
>    using the following URI: 'urn:scim:schemas:core:2.0:Schema'.  Unlike
>    other core Resources the Schema Resource MAY contain a complex object
>    within a Sub-Attribute and all Attributes are REQUIRED unless other
>    specified.
>
>    The following Singular Attributes are defined:
>
>    id The unique URI of the schema.  When applicable Service Providers
>       MUST specify the URI specified in the core schema specification;
>       e.g., "urn:scim:core:2.0:User".  Unlike most other schemas, which
>       use some sort of a GUID for the "id", the Schema "id" is a URI so
>       that it can be registered and is portable between different
>       Service Providers and Clients.
>
>    name  The Schema's human readable name.  When applicable Service
>       Providers MUST specify the name specified in the core schema
>       specification; e.g., "User" or "Group".  OPTIONAL.
>
>    description  The Schema's human readable description.  When
>       applicable Service Providers MUST specify the description
>       specified in the core schema specification.  OPTIONAL.
>
>    The following multi-valued attribute is defined:
>
>    attributes  A complex type that specifies the set of Resource
>       attributes.
>
>       name  The attribute's name.
>
>       type  The attribute's data type; e.g., String.
>
>       multiValued  Boolean value indicating the attribute's plurality.
>
>       description  The attribute's human readable description.  When
>             applicable Service Providers MUST specify the description
>             specified in the core schema specification.
>
>       readOnly  A Boolean value that specifies if the attribute is
>             mutable.
>
>       required  A Boolean value that specifies if the attribute is
>             required.
>
>       caseExact  A Boolean value that specifies if the String attribute
>             is case sensitive.
>
>       referenceTypes  The names of the Resource Types that may be
>             referenced; e.g., User.  This is only applicable for
>             attributes that are of the "reference" data type.
>
>             The following multi-valued attributes are defined.  There
>             are no canonical type values defined and the primary value
>             serves no useful purpose.
>
>             subAttributes  A list specifying the contained attributes.
>                      OPTIONAL.
>
>                      name        The attribute's name.
>
>                      type        The attribute's data type; e.g.,
>                                  String.
>
>                      description The attribute's human readable
>                                  description.  When applicable Service
>                                  Providers MUST specify the description
>                                  specified in the core schema
>                                  specification.
>
>                      readOnly    A Boolean value that specifies if the
>                                  attribute is mutable.
>
>                      required    A Boolean value that specifies if the
>                                  attribute is required.
>
>                      caseExact   A Boolean value that specifies if the
>                                  String attribute is case sensitive.
>
>                      referenceTypes  The names of the Resource Types
>                                  that may be referenced; e.g., User.
>                                  This is only applicable for attributes
>                                  that are of the "reference" data type.
>
>                      canonicalValues  A collection of canonical values.
>                                  When applicable Service Providers MUST
>                                  specify the canonical types specified
>                                  in the core schema specification;
>                                  e.g.,"work","home".  OPTIONAL.
> -----------------------
> 6.  SCIM User Schema
>
>    SCIM provides a schema for representing Users, identified using the
>    following URI: 'urn:scim:schemas:core:2.0:User'.  The following
>    attributes are defined in addition to those attributes defined in
>    SCIM Core Schema:
> 6.1.  Singular Attributes
>
>    userName  Unique identifier for the User, typically used by the user
>       to directly authenticate to the service provider.  Often displayed
>       to the user as their unique identifier within the system (as
>       opposed to id or externalId, which are generally opaque and not
>       user-friendly identifiers).  Each User MUST include a non-empty
>       userName value.  This identifier MUST be unique across the Service
>       Consumer's entire set of Users.  REQUIRED.
>
>    name  The components of the User's real name.  Providers MAY return
>       just the full name as a single string in the formatted sub-
>       attribute, or they MAY return just the individual component
>       attributes using the other sub-attributes, or they MAY return
>       both.  If both variants are returned, they SHOULD be describing
>       the same name, with the formatted name indicating how the
>       component attributes should be combined.
>
>       formatted  The full name, including all middle names, titles, and
>             suffixes as appropriate, formatted for display (e.g. Ms.
>             Barbara Jane Jensen, III.).
>
>       familyName  The family name of the User, or "Last Name" in most
>             Western languages (e.g. Jensen given the full name Ms.
>             Barbara Jane Jensen, III.).
>
>       givenName  The given name of the User, or "First Name" in most
>             Western languages (e.g. Barbara given the full name Ms.
>             Barbara Jane Jensen, III.).
>
>       middleName  The middle name(s) of the User (e.g.  Jane given the
>             full name Ms. Barbara Jane Jensen, III.).
>
>       honorificPrefix  The honorific prefix(es) of the User, or "Title"
>             in most Western languages (e.g. Ms. given the full name Ms.
>             Barbara Jane Jensen, III.).
>       honorificSuffix  The honorific suffix(es) of the User, or "Suffix"
>             in most Western languages (e.g. III. given the full name Ms.
>             Barbara Jane Jensen, III.).
>
>    displayName  The name of the User, suitable for display to end-users.
>       Each User returned MAY include a non-empty displayName value.  The
>       name SHOULD be the full name of the User being described if known
>       (e.g. Babs Jensen or Ms. Barbara J Jensen, III), but MAY be a
>       username or handle, if that is all that is available (e.g.
>       bjensen).  The value provided SHOULD be the primary textual label
>       by which this User is normally displayed by the Service Provider
>       when presenting it to end-users.
>
>    nickName  The casual way to address the user in real life, e.g. "Bob"
>       or "Bobby" instead of "Robert".  This attribute SHOULD NOT be used
>       to represent a User's username (e.g. bjensen or mpepperidge).
>
>    profileUrl  A fully qualified URL to a page representing the User's
>       online profile.
>
>    title  The user's title, such as "Vice President."
>
>    userType  Used to identify the organization to user relationship.
>       Typical values used might be "Contractor", "Employee", "Intern",
>       "Temp", "External", and "Unknown" but any value may be used.
>
>    preferredLanguage  Indicates the User's preferred written or spoken
>       language.  Generally used for selecting a localized User
>       interface.  Valid values are concatenation of the ISO 639-1 two
>       letter language code [15], an underscore, and the ISO 3166-1 2
>       letter country code [16]; e.g., 'en_US' specifies the language
>       English and country US.
>
>    locale  Used to indicate the User's default location for purposes of
>       localizing items such as currency, date time format, numerical
>       representations, etc.  A locale value is a concatenation of the
>       ISO 639-1 two letter language code [17], an underscore, and the
>       ISO 3166-1 2 letter country code [18]; e.g., 'en_US' specifies the
>       language English and country US.
>
>    timezone  The User's time zone in the "Olson" timezone database
>       format [19]; e.g.,'America/Los_Angeles'.
>
>    active  A Boolean value indicating the User's administrative status.
>       The definitive meaning of this attribute is determined by the
>       Service Provider though a value of true infers the User is, for
>       example, able to login while a value of false implies the User's
>       account has been suspended.
>
>    password  The User's clear text password.  This attribute is intended
>       to be used as a means to specify an initial password when creating
>       a new User or to reset an existing User's password.  No accepted
>       standards exist to convey password policies, hence Consumers
>       should expect Service Providers to reject password values.  This
>       value MUST never be returned by a Service Provider in any form.
> 6.2.  Multi-valued Attributes
>
>    The following multi-valued attributes are defined.
>
>    emails  E-mail addresses for the User.  The value SHOULD be
>       canonicalized by the Service Provider, e.g.  bjensen@...
>       instead of bjensen@....  Canonical Type values of work,
>       home, and other.
>
>    phoneNumbers  Phone numbers for the User.  The value SHOULD be
>       canonicalized by the Service Provider according to format in
>       RFC3966 [20] e.g. 'tel:+1-201-555-0123'.  Canonical Type values of
>       work, home, mobile, fax, pager and other.
>
>    ims  Instant messaging address for the User.  No official
>       canonicalization rules exist for all instant messaging addresses,
>       but Service Providers SHOULD, when appropriate, remove all
>       whitespace and convert the address to lowercase.  Instead of the
>       standard Canonical Values for type, this attribute defines the
>       following Canonical Values to represent currently popular IM
>       services: aim, gtalk, icq, xmpp, msn, skype, qq, and yahoo.
>
>    photos  URL of a photo of the User.  The value SHOULD be a
>       canonicalized URL, and MUST point to an image file (e.g. a GIF,
>       JPEG, or PNG image file) rather than to a web page containing an
>       image.  Service Providers MAY return the same image at different
>       sizes, though it is recognized that no standard for describing
>       images of various sizes currently exists.  Note that this
>       attribute SHOULD NOT be used to send down arbitrary photos taken
>       by this User, but specifically profile photos of the User suitable
>       for display when describing the User.  Instead of the standard
>       Canonical Values for type, this attribute defines the following
>       Canonical Values to represent popular photo sizes: photo,
>       thumbnail.
>
>    addresses  A physical mailing address for this User.  Canonical Type
>       Values of work, home, and other.  The value attribute is a complex
>       type with the following sub-attributes.  All Sub-Attributes are
>       OPTIONAL.
>       formatted  The full mailing address, formatted for display or use
>             with a mailing label.  This attribute MAY contain newlines.
>
>       streetAddress  The full street address component, which may
>             include house number, street name, P.O. box, and multi-line
>             extended street address information.  This attribute MAY
>             contain newlines.
>
>       locality  The city or locality component.
>
>       region  The state or region component.
>
>       postalCode  The zipcode or postal code component.
>
>       country  The country name component.  When specified the value
>             MUST be in ISO 3166-1 alpha 2 "short" code format [21];
>             e.g., the United States and Sweden are "US" and "SE",
>             respectively.
>
>    groups  A list of groups that the user belongs to, either thorough
>       direct membership, nested groups, or dynamically calculated.  The
>       values are meant to enable expression of common group or role
>       based access control models, although no explicit authorization
>       model is defined.  It is intended that the semantics of group
>       membership and any behavior or authorization granted as a result
>       of membership are defined by the Service Provider.  The Canonical
>       types "direct" and "indirect" are defined to describe how the
>       group membership was derived.  Direct group membership indicates
>       the User is directly associated with the group and SHOULD indicate
>       that Consumers may modify membership through the Group Resource.
>       Indirect membership indicates User membership is transitive or
>       dynamic and implies that Consumers cannot modify indirect group
>       membership through the Group resource but MAY modify direct group
>       membership through the Group resource which MAY influence indirect
>       memberships.  If the SCIM Service Provider exposes a Group
>       resource, the "value" sub-attribute MUST be the "id" and the
>       "$ref" sub-attribute must be the URI of the corresponding Group
>       resources to which the user belongs.  Since this attribute is
>       read-only, group membership changes MUST be applied via the Group
>       Resource (Section 8).  READ-ONLY.
>    entitlements  A list of entitlements for the User that represent a
>       thing the User has.  That is, an entitlement is an additional
>       right to a thing, object or service.  No vocabulary or syntax is
>       specified and Service Providers/Consumers are expected to encode
>       sufficient information in the value so as to accurately and
>       without ambiguity determine what the User has access to.  This
>       value has NO canonical types though type may be useful as a means
>       to scope entitlements.
>
>    roles  A list of roles for the User that collectively represent who
>       the User is; e.g., 'Student', "Faculty".  No vocabulary or syntax
>       is specified though it is expected that a role value is a String
>       or label representing a collection of entitlements.  This value
>       has NO canonical types.
>
>    x509Certificates  A list of certificates issued to the User.  Values
>       are Binary (Section 3.1.6) and DER encoded x509.  This value has
>       NO canonical types.
>
>
>


[identity-api-spec users] [jsr351-experts] some fragments from the SCIM schema

Ron Monzillo 01/21/2014

[identity-api-spec users] [jsr351-experts] Re: some fragments from the SCIM schema

Werner Keil 01/23/2014
 
 
Close
loading
Please Confirm
Close