At an enterprise level, role-based access control (RBAC) is a common service that is widely accepted as a best...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
practice for managing user authorizations. Even though RBAC operational best practices are still maturing, the technology has been implemented in some form by most organizations. Today, a vast majority of these deployments are based on commercially available, off-the-shelf products, with a few in-house developed services for customized features.
However, there's been a quiet groundswell of open source RBAC products that have been catching the eyes of seasoned identity management personnel. As they look to expand RBAC services within their organizations, the question comes up: "Are commercial products our only option for expansion, or can open source products be used as well?" In order to answer this question, an organization must know how easily these open source products can be integrated with their existing applications and whether they offer the same level of security as their paid-for counterparts.
Open source RBAC advantages
When looking at the commercial RBAC marketplace, it's important to note that some of the biggest players in the market aren't the biggest companies. Because RBAC's potential is still being realized, if a vendor can react faster to advancements in RBAC functionality, it can gain an advantage over its competitors. This positions smaller, boutique companies like Aveksa Inc., BHOLD Company and SailPoint Technologies Inc. in front of larger enterprise competitors like CA Inc., IBM and Sun Microsystems Inc. (recently acquired by Oracle Corp.).
This agility also translates well to open source RBAC products. Unlike their commercial counterparts, RSBAC, USRBAC, django-rbac, grsecurity and others, RBAC products were created by independent developers with the help of active user communities. Since these developers don't have the overhead commercial vendors do, open source providers can concentrate more of their efforts on enhancing their products. In addition, the developers generally improve and enhance their offerings through a formal, but speedy release-review process, which allows for innovations to be built into their products more quickly. Another important point is that the developers of open source RBAC products typically couldn't find products in the market that they felt met their high standards for capabilities and features. And in some cases, as with django-rbac, other developers who started writing their own open source RBAC products abandoned their efforts and joined forces with the django developers to provide a better product for all.
Another distinction that sets open source RBAC products apart from their commercial counterparts is that they generally work with a specific number of systems. For example, if an organization wants to provide an RBAC authorization scheme for smaller deployments focused on specific areas of the network, such as Active Directory, Unix or LDAP, rather than paying for an expensive commercial product that was designed to provide RBAC services to a large enterprise, the open source RBAC may be a cheaper, easier choice. In addition, by focusing on a single problem area, these tools tend to provide more in-depth capabilities with more configuration choices for improved deployment flexibility.
Open source RBAC also distinguishes itself from commercial products by not being concerned about market share. Since developers create open source RBAC code and release it to the world to be distributed as widely as possible, they don't include proprietary capabilities meant to lock in their clients. Instead they base their products on open, freely available standards, like the National Institute of Standards and Technology's (NIST) RBAC standard. Being based purely on standards, these products tend to interoperate with a broader number of other identity management products and the applications they support.
Open source RBAC disadvantages
While the advantages listed above make open source RBAC products attractive, organizations need to understand there's also a price to pay for these applications. The first is the investment in top-notch personnel. While open source RBAC has a great number of capabilities, its execution requires an in-depth knowledge of RBAC implementation. With wiki-based documentation, if any at all, and general command-line administrative interfaces, the people who manage the RBAC system must be senior employees knowledgeable in how to install, configure and execute RBAC.
Support for an open source product is also a consideration. While an open source RBAC product may have several intelligent developers behind the code, support generally takes the form of forums, mailing lists, wikis and IRC channels, rather than an 800-number or a staff of consultants and support personnel that can help with implementation or identifying and resolving problems with the code. This means that, while open source RBAC may provide greater technical capabilities, it's generally not business-friendly.
One of the benefits of open source RBAC is the limited scope the product provides, so an organization can target the systems on which it wishes to implement it, such as Active Directory, Unix, LDAP, etc. While this works well when the scope of the implementation includes only the immediate future, if a new system needs to be added that isn't supported by the open source RBAC product, other open source and/or commercial products must be brought in to integrate the new system into the existing RBAC architecture. In this case companies would do better to look at commercial RBAC products that are compatible with a wider range of high-value, strategically important systems.
There's also a misconception that open source RBAC products are free to license. The reality is that, while there are no mandatory financial obligations associated with the products, some, like grsecurity, request donations. And financially supporting a product that the organization uses for authorization functions is a smart move, as it's more likely to keep the intelligent developers committed to the project. However, even if you donate to the project, there's nothing to stop the developer from simply abandoning it and leaving further code support up to the user community.
Finally, whether an organization looks at open source RBAC or a commercial product, the architecture of implementing RBAC is still an art rather than a science. While commercial products generally have a staff of consultants to help with architecting an RBAC authorization model for a company, open source RBAC providers don't have the resources to help organizations plan out how their RBAC patterns will look.
Who should look at open source RBAC?
When deciding whether an open source RBAC product is a viable option, organizations must ask themselves a series of questions:
- Do we feel comfortable that our RBAC design is correct?
- Do we have a crack staff of RBAC professionals that we know can do the work themselves?
- Are we looking at deploying RBAC simply for a strategic end-point system?
- Are we looking for basic RBAC capabilities without the bells and whistles?
- Have we implemented, or will we implement, an enterprise RBAC product based on standards?
If an organization can answer 'yes' to all of these questions, then it's a great candidate for an open source RBAC product. If not, open source RBAC may fit its requirements, but careful study will be required to ensure success. In either case, there is a marketplace for open source RBAC amid the growing number of commercial offerings, but where they should be used and the value they may provide is still a matter of circumstance.
About the author:
Randall Gamby is an enterprise security architect for a Fortune 500 insurance and finance company who has worked in the security industry for more than 20 years. He specializes in security/identity management strategies, methodologies and architectures.