The Identity Cookbook

One of the most powerful concepts within OpenIDM, is the ability to create arbitrary managed objects on the fly, with hooks that can be triggered at various points of that managed objects life cycle.  A common use of managed objects is to separate logic, policy and operational control over a type of users.  However managed objects need not be just users, commonly they are devices, but they can also be used to manage relationship logic too - similar to how graph databases store relationship data separate to the entity being managed. For example, think of the basic relationship between a parent and child (read this article I wrote on basic parent and child relationships) . That article looked into the basic aspect of storing relationship data within the managed object itself - basically a pointer to some other object managed in OpenIDM. That in itself is powerful, but doesn't always cover more complex many-to-many style relationships. The above picture illustrates the concept of ex

This entry is the first in a mini-series, where I will attempt to explain some relatively complex terms and flows in the identity and access management space, in a way a 5 year could understand. Hopefully... First up is OAuth2 and  User Managed Access or UMA , a powerful federated authorization flow that sits on top of OAuth2 . Explain it like I’m 5: OAuth2 OAuth2 allows people to share data and things with other services that can access that data on their behalf.  For example, an individual might want to allow a photo printing service access to a few pictures from an album stored on a picture hosting service. Explain it like I’m 5: Resource Server The resource server is the service or application that holds the data or object that needs sharing.  For example, this could be the picture hosting site that stores the taken pictures. Explain it like I’m 5: Resource Owner The resource owner is the person who has the say on who can retrieve data from the resource server.  For example, this c