cloudfoundry/uaa — pull request #81 by wglasshusain (2014-04-28 01:19:20+00:00)
Title: Refactor UAA to allow developers to customize fields

Attached find a broad refactor of the UAA SCIM code to permit customization of the fields for SCIM users and groups. While this may seem like a large pull request, please note that

1. most of the changes are restructuring in nature. very little logic has changed
2. tests are unchanged (except for necessary changes to data types and method signatures). All pass.

The objective for this pull request is to enable developers to customize UAA with new fields for users, groups, and membership relationships. I think this is a broadly applicable use case. As an example, I have an application concerning corporate training classes and events. I use groups to indicate classes. Some fields I may want to add are

* User.Organization
* Group.Event and Group.EventDate
* Member.Role (where role is "student", "instructor", or "developer").

The UAA application by itself is unchanged in functionality, however it has been restructure to enable such customizations of fields for specific applications. This involves several broad changes.

1. Primary data structures ScimUser, ScimGroup, ScimGroupMember, ScimGroupExternalMember and ScimUserGroup (formerly part of ScimUser) now are concrete implementations of interfaces. The interfaces (e.g. ScimUserInterface) are used throughout the code rather than the concrete class.

2. Users wishing to add custom fields to (for example) ScimUser, may create a new implementation of ScimUserProvisioning which returns a subclass of ScimUser with additional fields that can be stored/retrieved from a database. There's little change to UAA for this part, since the provisioners are already interfaces. I did however reorganize the packages to separate interfaces from implementations.

3. To convert JSON request bodies with additional fields into (example) CustomScimUserObject, new Json serializers and deserializers are needed. I have reorganized the code in ScimUserJsonDeserializer and similar fields to aid subclassing.

In order to make use of these changes, the developer may simply copy/edit the "uaa" subproject in the "uaa" folder, and change the spring beans to use the new provisioners. I have also (in my application) injected a custom configured Jackson ObjectMapper which substitutes in the new serializers/deserializers so that the "common" and "scim" project can be imported unchanged.

I'm interested in feedback from other developers. Does this seem like a good way to go? If so, I can create a sample project showing how to customize a user or group with additional fields and this could be included in the distro.

I am hoping this works out, as we would like to further develop our application based on UAA rather than do a separate identity server or permanent fork.