It’s easy to confuse authentication with authorization. The two are frequently used interchangably in conversation and are often tightly associated as key pieces of web service infrastructure. But the two are really two different concepts which often are completely divorced from each other. Authentication is the process where by an individual’s identity is confirmed. Whereas authorization is the association of that identity with rights and permissions.
Put another way, when you hand your driver’s license over to a police officer, the officer can confirm that you are authorized to drive a car, motorcycle, or commercial vehicle. When you hand the same license over at the theater box office, you are authenticating that you are the person who ordered the tickets for the show.
In the Enterprise, there frequently is a decoupling of authentication and authorization which is entirely hidden from the end-user. The Windows Active Directory system authenticates the user when they login and that identity confirmation is then used by various licensing systems to authorize or otherwise allow access to applications.
In the web services space, there have been a number of attempts over the years to provide authentication services with the idea of a single sign-on across your Internet accounts. Microsoft Passport was a particularly well known failed example along with a number of other lesser known initiatives and companies.
Today, Google, Facebook, and Twitter all provide federated authentication services which any web site or application can use to verify the identity of someone. Additionally, OAuth is a proposed open standard for authentication which promises ease of integration and strong authentication services. And for the Enterprise that wishes to use a cryptographically strong multi-factor authentication service, SafeNet’s BlackShield product fits the bill. None of these solutions, however, provide an answer for authorization.
While some big players have stepped in to the authentication space, the developer of web applications has been often left to their own devices. This often leads to a simple yes/no on the rights and permissions for the authenticated user across an entire web application. Usually, this is enough for simple applications or early on in the development cycle. But as applications grow and add features, there is a push to better monetize and control who has access to those features.
Attempting to graft on feature-level permissions after the fact can be time consuming, cost prohibitive, and takes time away from developing the core of your application.
Sentinel Cloud Services provides feature level licensing as a service. With simplified calls, either to a runTime library or through a secure REST API, the developer can easily connect the features you wish to control with the service. The developer is no longer encumbered with creating a licensing infrastructure and can focus on getting your application to market faster, with more features, and greater maturity.