MyIdentityGraph
In the age of Consumer Identity and Internet of Things (IoT), identity data gets more and more complex. Especially the relationship between Persons and Things need to have an adequate representation. Access rights must be easily recognizable and quickly evaluated.
MyIdentityGraph stores identity data in a Graph database which represents Persons, Resources and Devices as Vertices (Nodes) and the relationship between the Vertices as Edges. For example, a Person owns his UserProfileData. In that case the Person and UserProfileData are represented as Vertices and the relationship “owns” is an Edge between these Vertices.
MyIdentityGraph introduces a ReBAC (Relationship Based Access Control) entitlement service based on XACML, a commonly used policy language for authorization. The ReBAC entitlement server acts as AzaaS (Authorization as a Service) providing a REST interface to answer questions like “Has Person A access to Device B owned by Person C”. The interface supports JSON/REST profile of XACML.
These questions are translated into Graph queries as “Is there a path from Person A to Device B” whereas a path means “Access Path” and can be naturally expanded to reflect relations like delegated access rights.
Let’s look at an example. Throughout our use cases we will use the following actors.
Saskia has access to UserProfileData “Owen” because an “read access edge” between Saskia and the UserProfileData “Owen” exists. Note: the image below displays another UserProfieData vertex – this is her own data easily recognizable by the edge with verb “owns”.
OR
Permission with Delegation (see image)
Person A (Delgado) might have access to Resource UserProfileData “Owen” of resource owner Ron B because there is an “access edge” between Saskia and Ron’s UserProfileData and a “delegation edge” between Delgado and Saskia
In the latter case a path from Person A to Device B exists by travelling the delegation edge to Person X and then using the “access edge” to Device B
We hope that the example demonstrates how powerful such a representation might be.
Returning to Authorization as a Service: MyIdentityGraph AzaaS supports *-BAC (pronounce StarBAC), a combination of ReBAC, ABAC and RBAC. To establish such a service a usable and accepted access protocol is needed. XACML paved the way but still lacks acceptance. With XACML JSON Profile request and response interface the situation will be improved. But there is more to AzaaS than just asking for permission. MyIdentityGraph supports requesting and approving permissions by end users to resources owned by another person. This enables a resource owner to control permissions and sharing of his resources
SSOCircle MyIdentityGraph combines a Graph representation of Identities, a XACML JSON Request/Response based ReBAC authorization service (AzaaS), and OAuth standard based communication protocols
With UMA (user managed access) there is an OAuth-based access management standard which facilitates the interaction between a resource owner, the access requesting party, the service itself and the protected resources. Support of UMA is planned for upcoming releases of MyIdentityGraph.
More details about the MyIdentityGraph Ontology, AzaaS and ReBAC can be found in the Knowledge Center.
MyIdentityGraph is currently in Beta but integrated in the SSOCircle Public IDP. Ontology and the database itself is subject to change and may taken offline from time to time. Database content especially relations may be reset frequently Registered SSOCircle Public IDP user have access to it at MyIdentityGraph