NEEDS UPDATE

SCIM Data Structure

The SCIM data structure shall be a data structure for storing, retrieving and modifying a SCIM. The SCIM data structure shall have constructors capable of building the SCIM data structure from:

  • A SCIM represented as a JSON string

  • A SCIM represented as a JSON file

  • An LDIF and a SCIM Mapping in YAML format.

The SCIM data structure shall expose a method named Get which takes a fully qualified key in as a String, and returns the value of the named attribute. The fully qualified key takes the form of attribute.subAttribute. Keys for Schema extensions should not be qualified by schema type.

Example:

SCIM Attribute

SCIM Sub-attribute

Fully Qualified Key

id


id

name

formatted

name.formatted

employeeNumber


employeeNumber



The SCIM data structure shall also expose a method named Set which takes a fully qualified key in as a String, and the new value as an Object and sets the named attribute to have the value provided. This method shall check against the schema and will follow the mutability rules provided by the SCIM standard


The SCIM Data structure shall contain a static member of the ScimSchema class to be used for validation. See § 1.1.


Jackson: https://github.com/FasterXML/jackson

Note: Jackson is a JSON parser / generator. Jackson can also be used to parse / generate YAML.



§ 1.1 –SCIM Validation

Validation shall be handled by the SCIM Data structure using the ScimSchema class to get access to the underlying schema. The ScimSchema class shall construct itself from a list of JSON files containing the schema(s). During construction ScimSchema shall create a ScimSchemaAttribute object for each of the attributes and sub-attributes defined. The ScimSchema class shall expose a method name Get which takes a string in the form of a fully qualified key as described in § 1 and returns the matching ScimSchemaAttribute object.

The ScimSchemaAttribute object type shall contain publicly accessible members for the following properties as described in the SCIM standard; name, type, multi-valued, description, required, case exact, mutability, returned and uniqueness.

Using the data provided by the ScimSchema class the Scim class shall enforce the following requirements;

  • The value must be of the type described by type

  • The value must be or not be a multi-valued object as described by multivalued

  • The value must be present if required

§ 2 –LDIF Data Structure

The LDIF data structure shall be a data structure for storing, retrieving, and editing LDIFs. The LDIF data structure shall have constructors capable of building the LDIF data structure from

  • An LDIF represented as a string

  • An LDIF stored in a file

  • A SCIM, A LDIF mapping, and an LDAP Operation Type.


The LDIF class shall expose a method named Get which takes a String representation of the attribute’s name as key and retrieves the value from the LDIF. The LDIF class shall also expose a method named Set which takes a String key and an a value, and changes the attribute named by key to have the value provided.


Note: LDIF is a flat file structure so there are no sub-attributes. As such fully qualified keys are not necessary to identify an attribute uniquely.




§ 3 –Conversion Instructions (YAML)

§ 3.1 –Lookup Tags

Lookup tags ${} are stored inside the mappings and are replaced with specific values.

The format used to identify an attribute is source.attribute.sub-attribute. Where source may be either scim, ldif or this. In the case of this, what this translates to will change depending on context. If this is used from within a ldif attribute then this will refer to ldif. If this is used from within a scim attribute then this will refer to scim. If this is use from within a scim sub-attribute then this will refer to the parent attribute scim.attribute.

§ 3.2 –SCIM to LDAP

Conversion instructions from SCIM to LDAP will take the form of a LDIF file. The object classes required must be contained in the LDIF file. Each ldif attribute will contain a string describing how to to construct the value of that attribute from SCIM attributes. The file may also refer to it own elements using the source this. A mapping file using the this source may not have any circular references.

The attribute ID must match the LDIF attribute DN.

§ 3.3 –LDAP to SCIM

Conversion instructions from LDAP to SCIM will take the form of a SCIM in the YAML file format. Values for each attribute will contain a string describing how to construct the value of that attribute from LDIF attributes. The file may also refer to its own elements using the source this. A mapping file using the this source may not have any circular references.



§ 4 –Rest Endpoints

§ 4.1 –GET Endpoints

These operations are used to retrieve information from the SCIM endpoint. The information received depends on which endpoint the information is requested from. GET operations only require that the ID of the resource to be retrieved.

For the purposed of retrieving information from an LDAP target system the ID of the SCIM object must match the dn of the desired resource on the target system, so that ldapsearch may be used to retrieve the entry.

§ 4.1.1 –/ServiceProviderConfig

This endpoint returns the Service Provider Configuration see the specification below for its’ definition

Specification: https://tools.ietf.org/html/rfc7643#section-5

Example: https://tools.ietf.org/html/rfc7643#section-8.5

§ 4.1.2 –/ResourceTypes

This endpoint returns the Resource Types supported by this service provider, see the specification below for the formal definition.

Specification: https://tools.ietf.org/html/rfc7643#section-6

Example: https://tools.ietf.org/html/rfc7643#section-8.6

§ 4.1.3 –/Schemas

This endpoint returns the Schemas supported by this service provider, see the specification below for the formal definition.

Specification: https://tools.ietf.org/html/rfc7643#section-7

Example: https://tools.ietf.org/html/rfc7643#section-8.7

§ 4.1.4 –/Users/{id}

This endpoint returns the User identified by {id}

Specification: https://tools.ietf.org/html/rfc7644#section-3.4.1

§ 4.1.5 –/Groups/{id}

This endpoint returns the Group identified by {id}

Specification: https://tools.ietf.org/html/rfc7644#section-3.4.1

§ 4.1.6 –/Schemas/{id}

This endpoint returns the Schema identified by {id}

Specification: https://tools.ietf.org/html/rfc7644#section-3.4.1

§ 4.1.7 –/{resource}/Me

This endpoint should return HTTP Status Code 501 (Not Implemented)



§ 4.2 –POST Endpoints

Post operations are used to create new entries. Post operations should be translated to changetype: add operation. A new User or Group should be created depending on which endpoint was used /Users or /Groups respectively.


Specification: https://tools.ietf.org/html/rfc7644#section-3.3

§ 4.2.1 –/Users

This post operation should create a new user from the SCIM data received

§ 4.2.2 –/Groups

This post operation should create a new group from the SCIM data received

§ 4.2.3 –/Bulk

Out of scope.

Specification: https://tools.ietf.org/html/rfc7644#section-3.7

§ 4.2.4 –/{resource}/Me

This endpoint should return HTTP Status Code 501 (Not Implemented)

§ 4.2.5 –/{resource}/.search

This endpoint should search for the entry who contains the attribute/value supplied by the scim.

Specification: https://tools.ietf.org/html/rfc7644#section-3.4.3



§ 4.3 –§ 5.3 - PUT Endpoints

PUT operations are used to replace entire entries. A put requires that every attribute provided is replaced with the data provided. Read Only attributes shall be ignore, and any input values given for immutable attributes must match the value(s) that already exists for said attribute. PUT Operations shall be translated to changetype: modify operations, where every attribute given is marked to be replaced with the values given in the scim.

Example:

dn: cn=Joe Schmoe, dc=example, dc=com

changetype: modify

replace: attribute1

attribute1: NewValue1

replace: attribute2

attribute2: NewValue2


Specification: https://tools.ietf.org/html/rfc7644#section-3.5.1

§ 4.3.1 –/Users/{id}

This PUT operation should modify an existing user, identified by {id}, using the SCIM data received.

§ 4.3.2 –/Groups/{id}

This PUT operation should modify an existing group, identified by {id}, using the SCIM data received.

§ 4.3.3 –/{resource}/Me

This endpoint should return HTTP Status Code 501 (Not Implemented)



§ 4.4 –PATCH Endpoints

The standard lists implementation of PATCH as optional. PATCH operations are used to modify multiple attributes. PATCH operations will use changetype: modify along with add: attribute, replace: attribute, and/or delete: attribute, as necessary, per attribute modified, keeping in mind that replace and delete have two versions each.

Example:

dn: cn=Joe Schmoe, dc=example, dc=com

changetype: modify

add: attributeToAdd

attributeToAdd: value1

-

replace: attributeToReplaceWithOneValue

attributeToReplaceWithOneValue: value2

-

replace: attributeToReplaceWithMultipleValues

attributeToReplaceWithMultipleValues: firstValue

attributeToReplaceWithMultipleValues: secondValue

-

delete: attributeToDelete

-

delete: specificAttributeToDelete

specificAttributeToDelete: valueToSearchForAndDelete

-

Specification: https://tools.ietf.org/html/rfc7644#section-3.5.2

§ 4.4.1 –/Users/{id}

This PATCH operation should modify an existing user, identified by {id}, using the SCIM data received.

§ 4.4.2 –/Groups/{id}

This PATCH operation should modify an existing group , identified by {id},using the SCIM data received.

§ 4.4.3 –/{resource}/Me

This endpoint should return HTTP Status Code 501 (Not Implemented)


§ 4.5 –DELETE Endpoints

This operation is used to delete entries. DELETE operations are used to remove an entire entry. DELETE operations will use changetype: delete. For this operation the only information required is the dn of the entry to be remove.


Specification: https://tools.ietf.org/html/rfc7644#section-3.6

§ 4.5.1 –/Users/{id}

This DELETE operation should delete an existing user, identified by {id}, using the SCIM data received.

§ 4.5.2 –/Groups/{id}

This DELETE operation should delete an existing group , identified by {id},using the SCIM data received.

§ 4.5.3 –/{resource}/Me

This endpoint should return HTTP Status Code 501 (Not Implemented)

§ 5 –Send LDIF over LDAP

Integrate UnboundID Java SDK and use it to serialize the LDIFs generated, and send them over LDAP to the Target system.

§ 6 –Create Test Framework

Create JUnit tests that cover the code.

  1. LDAP Operation Types

    1. add

This change type is used to add a new entry.

dn: cn=Joe Schmoe, dc=example, dc=com
changetype: add
cn: Joe Schmoe
postaladdress: 123 main street, Des Plaines, IL, 60016

    1. modrdn

    This change type modifies the Relative Domain Name (rdn), which is the front part of the Distinguished Name (dn) before the first comma (,). This operation will add a new cn, unless deleteoldrdn is set to 1 (true). Once this example operation is complete, Joe’s should have two cn entries. One for Joe Schmoe, and one for Joseph Schmoe. His dn should have been changed such that it uses the new cn Joseph Schmoe.

    dn: cn=Joe Schmoe, dc=example, dc=com
    changetype: modrdn
    newrdn: cn=Joseph Schmoe
    deleteoldrdn: 0

      1. delete

      This change type is used to delete an entire entry.

      dn: cn=Joe Schmoe, dc=example, dc=com
      changetype: delete

        1. modify

        This changetype allows for adding new attributes, removing attributes, or replacing the value of an attribute. There are several modification operations supported by the modify changetype.

            1. add

            this operation adds a new attribute

            dn: cn=Joe Schmoe, dc=example, dc=com
            changetype: modify
            add: postaladdress
            postaladdress: 123 main street, Des Plaines, IL, 60016

                1. delete

                this operation has two forms. If a value is specified it looks for and deletes the ma​_tching value. If no value is specific for the attribute then every value for that attribute is to be removed.

                      1. Delete an Entry

                      dn: cn=Joe Schmoe, dc=example, dc=com
                      changetype: modify
                      delete: postaladdress

                            1. Delete a Specific Entry

                            dn: cn=Joe Schmoe, dc=example, dc=com
                            changetype: modify
                            delete: postaladdress
                            postaladdress: 123 main street, Des Plaines, IL, 60016

                                1. replace

                                This operation replaces the attribute named with the value specified. If multiple values are specified then, all the previous values will be removed and replaced by the values specified.

                                      1. Replace Current Value with one Value

                                      dn: cn=Joe Schmoe, dc=example, dc=com
                                      changetype: modify
                                      replace: telephonenumber
                                      telephonenumber: +1 408 555 1234

                                            1. § 4.3.1 - Replace With Multiple Values

                                            dn: cn=Joe Schmoe, dc=example, dc=com
                                            changetype: modify
                                            replace: telephonenumber
                                            telephonenumber: +1 408 555 1234
                                            telephonenumber: +1 408 555 5678