OverviewProvide a "Server Tier" interface that would enable OpenPTK to become a Simple Cloud Identity Management (SCIM) 1.0 compliant Service Provider / Server. This implementation of the SCIM 1.0 specification should implement the following OpenPTK Operations: - Create
- Read
- Update
- Delete
- Search
ReferenceProjects
Issues
RequirementsService Provider Information "well known" URL : "/ServiceProviderInfo" This is the meta-data access point … clients discover server's capabilities This appears to be a "root" url requirement. Would probably have to develop a simple "class" to support this Have it configured in "web.xml" to listen on /ServiceProviderInfo resource end-point names: /Users and /{version)/Users Use "alias" feature to map this pattern to a "contexts/{context}/subjects" url mime type declaration via "suffix" schemas: User and Group Authentication spec says … need to support "it" … recommend OAuth, will support Basic
SCIM 1.0 SpecificationData Types
The SCIM interface supports different ways to represent data. A SCIM attribute can use sub-attribute to group together "like" attributes. OpenPTK does not support this type of data format (complex attribute). An attribute with sub-attributes will need to transformed to a single-level attribute. The table below summarizes the different attribute types/formats
Supported Data Types:
- String
- Boolean
- Decimal
- Integer
- DateTime
- Binary
- Complex
Name | Description | JSON Example | XML Example | Single
| Only one level and has zero or one value | {
"userName":"jdoe"
} | <userName>bjensen@example.com</userName> | Multi | Only one level with multiple values. The values are elements of an array.
Elements of the array can be just values or other object types. | { "emails" : [ "jdoe@work.org", "john@work.net" ] } -or- { "emails" : [ { "value" : "jdoe@work.org" }, { "value" : "john#home.net" } ] } -or- {
"emails" : [
{ "value" : "jdoe@work.org", "type" : "work", "primary" : true },
{ "value" : "john@home.net", "type" : "home" }
]
}
| <emails> <email>jdoe@work.org</email> <email>john@work.net</email> </emails> -or- <emails> <email> <value> jdoe@work.org</value> <type>work</type> <primary>true</primary> </email> <email> <value> john@home.net</value> <type>home</type> </email> </emails> | Complex | Contains one or more sub-attributes. The sub-attributes are typically Single types | "name": { "formatted": "Mr. John Doe Sr.", "familyName": "Doe", "givenName": "John", "middleName": "Henry", "honorificPrefix": "Mr.", "honorificSuffix": "Sr." } | <name>
<formatted> Mr. John Doe Sr.</formatted> <familyName>Doe</familyName> <givenName>John</givenName> <middleName>Henry</middleName> <honorificPrefix>Mr.</honorificPrefix> <honorificSuffix>Sr.</honorificSuffix> </name>
|
Schema::Core
Name: | id | Type: | single | Description: | Unique identifier for the SCIM Resource as defined by the Service Provider | JSON Example: | {
"id":"2819c223-7f76-453a-919d-413861904646"
} | XML Example: | <id>2819c223-7f76-453a-919d-413861904646</id> |
Name: | externalId | Type: | single | Description: | Unique identifier for the Resource as defined by the Service Consumer | JSON Example: | {
"exernalId" : "701984"
} | XML Example: | <externalId>701984</externalId> |
Name: | meta | Type: | complex single | Description: | A complex attribute containing resource metadata. All sub-attributes are OPTIONAL:
- created
- lastModified
- location
- version
- attributes
| JSON Example: | {
"meta" : {
"created" : "2010-01-23T04:56:22Z",
"lastModified" : "2011-05-13T04:42:34Z" }
} | XML Example: | <meta>
<created>2010-01-23T04:56:22Z</created>
<lastModified>2011-05-13T04:42:34Z</lastModified>
</meta> |
Schema::User
Name: | userName | Type: | single | Description: | 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. It MUST be a stable ID that does not change when the same User is returned in subsequent requests. REQUIRED | JSON Example: | {
"userName":"jdoe"
} | XML Example: | <userName>jdoe</userName>
|
Name: | name | Type: | complex single | Description: | 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
- familyName
- givenName
- middleName
- honorifixPrefix
- honorifixSuffix
| JSON Example: | { "name": { "formatted": "Ms. Barbara J Jensen III", "familyName": "Jensen", "givenName": "Barbara", "middleName": "Jane", "honorificPrefix": "Ms.", "honorificSuffix": "III" } } | XML Example: | <name> <formatted>Ms. Babs J Jensen III</formatted> <familyName>Jensen</familyName> <givenName>Barbara</givenName> <middleName>Jane</middleName> <honorificPrefix>Ms.</honorificPrefix> <honorificSuffix>III</honorificSuffix> </name> |
Name: | displayName | Type: | single | Description: | 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. | JSON Example: | {
"displayName" : "John R Doe"
} | XML Example: | <displayName>John R Doe</displayName> |
Name: | nickName | Type: | single | Description: | 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). | JSON Example: | {
"nickName" : "Johnny"
} | XML Example: | <nickName>Johnny</nickName> |
Name: | profileUrl | Type: | single | Description: | A fully qualified URL to a page representing the User's online profile. | JSON Example: | {
"profileUrl" : "http://profiles.net/jdoe"
} | XML Example: | <profileUrl>http://profiles.net/jdoe</profileUrl> |
Name: | title | Type: | single | Description: | The user’s title, such as “Vice President.” | JSON Example: | {
"title" : "Manager"
} | XML Example: | <title>Manager</title> |
Name: | userType | Type: | single | Description: | 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. | JSON Example: | {
"userType" : "Employee"
} | XML Example: | <userType>Employee</userType> |
Name: | preferredLanguage | Type: | single | Description: | 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, an underscore, and the ISO 3166-1 2 letter country code; e.g., 'en_US' specifies the language English and country US. | JSON Example: | {
"preferredLanguage":"en_US"
} | XML Example: | <preferredLanguage>en_US</preferredLanguage> |
Name: | locale | Type: | single | Description: | 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 theISO 639-1 two letter language code, an underscore, and the ISO 3166-1 2 letter country code; e.g., 'en_US' specifies the language English and country US. | JSON Example: | { "locale":"en_US" } | XML Example: | <locale>en_US</locale> |
Name: | timezone | Type: | single | Description: | The User's time zone in the "Olson" timezone database format; e.g.,'America/Los_Angeles'. | JSON Example: | { "timezone": "America/Chicago" } | XML Example: | <timezone>America/Chicago</timezone> |
Name: | active | Type: | single | Description: | 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. | JSON Example: | { "active":true } | XML Example: | <active>true</active> |
Name: | password | Type: | single | Description: | 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. | JSON Example: | { "password":"t1meMa$heen" } | XML Example: | <password>t1meMa$heen</password> |
Name: | VALUE | Type: | single | Description: |
| JSON Example: |
| XML Example: |
|
|