A Beginners Guide to OpenIDM – Part 2 – Objects & Relationships
- User: User identities, effectively this is your central identity store.
- Role: An object for modelling roles.
- Assignment: An object for modelling assignments. Assignments are effectively ways of capturing sets of entitlements across mapping. Which can then be associated with roles.
- Organisations, divisions, teams or other parts of a business.
- Devices and hardware.
- Products and offerings.
- Anything else you can think of! Managed objects are completely configurable.
- Which organisations a user belongs to.
- The devices that a user owns.
- The products a user has.
- The teams that belong to an organisation.
- Anything else you can think of!
- Details: The name and icon that represents the object in the UI.
- Schema: Properties, their validation rules and their relationships.
- Scripts: Different hooks for running scripts throughout the object lifecycle e.g. postCreate
- Properties: Rules for special attribute behaviors e.g. passwords should be encrypted and private.
- Property Name: The internal name users within the OpenIDM platform to refer to the property, think of it like a variable name only used internally.
- Readable Title: The name that will be used to refer to the property in the user interface.
- Description: Simple description of the attribute that when populated is used throughout the interface as a tooltip.
- Viewable: Can it be seen in the UI?
- Searchable: Is it indexed and searchable in the UI?
- End users allowed to edit: Used are allowed to update the value using self service.
- Minimum Length: Minimum length of the attribute value.
- Pattern: Any specific pattern to which the value of the property must adhere. e.g. date formats.
- Validation Policies: Rules that can be used to define attribute behavior. We will look at these in detail in a moment.
- Required: Must be populated with a value.
- Return by Default: If true, will be returned when user details are requested via the API. If false, will only be returned if specifically asked for.
- Type: Type of the attribute: String, Array, Boolean, Integer, Number. Object or Relationship. We will look at relationships in a moment.
- User’s have a manager. This is a Relationship. It is in fact a reverse relationship. As manager A, has reports X,Y,Z and reports X,Y,Z have the manager A.
- User’s can also have reports. They may have multiple reports. Note this is an Array of Relationships: A manages X, A manages Y, A manages Z. Likewise this is a reverse relationship.
- Script – Inline Script: script defined within the UI.
- Script – File Path: a script stored within the OpenIDM configuration directory. This is how out of the box scripts work. If you navigate to /openidm/bin/defaults/script/ui you can examine these out of the box scripts to see what they do.
- Workflow – Event can be used to trigger a workflow.
- Encrypted: The attribute value is encrypted. This means it can be decrypted and the value retrieved if required.
- Private: Restricts HTTP access to sensitive data, if this is true the attribute is not returned when using the REST API.
- Virtual: The attribute is calculated on the fly, usually from a script.
- Hashed: The attribute is hashed. Hashing is a one way function and the usual way that passwords should be stored. You hash the password when a user registers for the first time. When they log in again subsequently you hash the password that they enter against the original password hash. If they match you know the passwords are the same. Crucially, it is impossible to take a hash and extract the original password from it.
Managed Objects and the REST API
This blog post was first published @ http://identity-implementation.blogspot.no/, included here with permission from the author.