LDAP Connector
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.
LDAP Operation Types
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
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
delete
This change type is used to delete an entire entry.
dn: cn=Joe Schmoe, dc=example, dc=com
changetype: delete
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.
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
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.
Delete an Entry
dn: cn=Joe Schmoe, dc=example, dc=com
changetype: modify
delete: postaladdress
Delete a Specific Entry
dn: cn=Joe Schmoe, dc=example, dc=com
changetype: modify
delete: postaladdress
postaladdress: 123 main street, Des Plaines, IL, 60016
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.
Replace Current Value with one Value
dn: cn=Joe Schmoe, dc=example, dc=com
changetype: modify
replace: telephonenumber
telephonenumber: +1 408 555 1234
§ 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