If you’re using a business application, it is very likely to have a user repository attached. This is usually a simple database containing an ID and list of authorized actions for each user. It’s a simple system, and as a 2014 survey showed, its downfall is that the average enterprise has over 500 applications in use. We know that the number is closer to 500,000 applications running per enterprise. With one repository per application, the challenge of managing these repositories cannot be understated.
Several solutions have been tried, with LDAP (Lightweight Directory Access Protocol) as the most popular. This is, in effect, is a single directory designed to share user and authorization information between many applications. Its advantages are that it is an industry standard designed so that every developer can freely integrate it into their product. The drawback however, is that it didn’t fit all AuthZ needs and so wasn’t widely adopted.
In addition to the problem of volume, repositories have drawbacks common with other traditional forms of AuthZ.
Administration: In order to change permissions for a given application, the repository needs to be updated. Either manually or by a provisioning system, in both cases it’s a complicated task that requires time and resources.
No Flexibility: Authorizations don’t change based on any variables. For example, a cyber security event, or user login through a mobile device, won’t remove any assigned permissions. . Repositories are static, however, and their users & permissions must be programmed in advance.
Inefficient Distribution: With over 500 repositories in the average enterprise, the problem isn’t just a matter of scale. It is difficult to apply AuthZ policy consistently over such a large volume of databases. If the AuthZ policy isn’t applied consistently – whether due to accident or indifference, then certain applications may become security risks.
Virtual tokens take one of the traditional aspects of AuthZ and flips it on its head. What if, instead of storing authZ information in large repositories within each application, you instead reduce it to a small repository fitted for an individual user? This is what a virtual token represents. Upon access, this token is sent to the application, which responds accordingly.
This approach displays some marked advantages over the traditional repository approach. For one, it’s responsive -the data carried by the virtual token allows the application to respond dynamically based on conditions described by the AuthZ token. Secondly, virtual tokens are allowed to be small, containing only the information that’s necessary for the app to authenticate and authorize the user.
Lastly, virtual tokens reduce the need to maintain all those repositories, so no more unmanaged AuthZ, no more “ghost” IDs.
PlainID’s AuthZ platform support both, repository based and token based AuthZ. We talk all AuthZ languages, whether it’s LDAP or OAuth, Active directory or XACML. Same AuthZ business policy can be used in different technical implementations.. If your enterprise is moving from one schema to another, you’ll find that PlainID can move with you.
IAM teams can also use PlainID to support mobile applications, cloud implementations, beef up application security, and make extremely precise changes to authorizations using a central decision point. For more information on how to use PlainID to improve efficiency and security: 