Skip to main content

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

  • From: Ron Monzillo <ron.monzillo@...>
  • To: jsr351-experts@...
  • Subject: [identity-api-spec users] [jsr351-experts] some fragments from the SCIM schema
  • Date: Tue, 21 Jan 2014 13:45:04 -0500
  • List-id: <jsr351-experts.identity-api-spec.java.net>

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