This article continues the discussion started in the Authorization as a Service article.
Within Account Manager 5 is a versatile foundation for working with and authorizing against enterprise identity and entitlement information. This foundation begins with a flexible entity model partitioned by organization, and a generic authorization model that accommodates Roles-Based Access Control(RBAC), Attribute-Based Access Control (ABAC), and Risk-Based Authentication (RBA). The internal authorization implementation is called Participation Access Control, on which the Effective Authorization Service and Authorization as a Service service are based.
Authorization as a Service is exposed as the Policy Service REST interface. An authorization client requests a Policy Definition for a given Policy, which includes context information, expiry instructions, and a list of expected parameters. A Policy Request can be created from the Policy Definition, and parameterized values may be specified for the defined parameters. The Policy Evaluator translates the parameters into Facts, which are then used during the evaluation of the rules and patterns attached to the policy. At the end of evaluation, the Policy Response includes the response state, any risk score, and the pattern chain used to evaluate the policy. A key feature of the Policy Service is that authorization operations, such as asserting role participation or entitlement affect are pre-calculated through the Effective Authorization Service at the time the data is loaded. Therefore, the Policy Service has access to an emulated view of a given set of enterprise identities, accounts, applications, permissions, roles, data, and data rights.
Each cluster of enterprise identity data is logically separated by organization, and then by group and/or parent. Account Manager requires that all entity objects be owned, limiting default access to the owner and administrator, and safeguarding it from accidental exposure. Further more, values and certain objects may be encrypted using one of several integrated encryption layers (Cryptography currently supplied by BouncyCastle). Persons, Accounts, and Groups are all scoped by Group and then Organization, while Roles and Permissions are scoped by parent and then Organization. A snapshot of enterprise data is represented by a group of Persons, a group of applications, and forks in the Role and Permission trees. Applications are represented as named groups, into which Accounts are stored. If the Person to Account relationship is provided, as well as Application entitlements and entitlement memberships, then the Effective Authorization Service will calculate the effective permissions for a person via a linked account and that account's permissions. If a role hierarchy is loaded, and application entitlements and person memberships specified, then the Effective Authorization Service can also show the base and effective role entitlements. Each type of entity supports multi-valued ad-hoc attributes, which then allow the Policy Service to evaluate attribute-based access.
The Policy Service's internal authorization procedures understand a set of predefined Factory types, including persons, accounts, users (not represented here), attributes, roles, groups, and permissions. When executing Authorization rules, the referenced Factory types are retrieved and then evaluated through the Effective Authorization Service. This allows for rules that assert for indirect permission and indirect role participations, without supplying any of those references. Authorization assertions are limited to discrete values because the Policy Definition and supplied parameter templates include the necessary context, and all non-parameter facts remain on the server. For example, consider a person with twenty accounts, some role memberships in a role hierarchy, and any number of application entitlements. Does a Person have an Account with a Permission (entitlement) inherited from a Role? Or, Does a Person have an Account with a Permission and a custom attribute value on either the account or the permission? This type of policy can be written by bulking loading data and defining the policy rules, and executed with only a reference to the Person. No PIPs, no lengthy attribute lists, no custom data schemas, no complicated or abstract authorization languages (looking at you, XACML). For another example, this model has been used to rapidly bulk-synchronize with IBM Security Identity Manager, including extracting role hierarchy and entitlements. Once that data was loaded it was immediately available (to an authorized user, of course) for use by the Policy Service.
After having worked with identity and access management for a number of years now, including access governance, entitlements, and solving some very interesting challenges, I've been bereft of any decent solution for externalizing authorization into a cloud-based offering. There exist a number of standards and common industry practices for externalizing business rules and entitlements into policies and workflows, but Authorization as a Service has been vaguely defined. That uncertainty may stem from the deep overlaps between IdaaS and an entitlements or rules engine, while ignoring the necessary separation that must exist in a cloud-based offering. Then, sometime last night while having one of those weird dreams of being in a a forest of complex geometric patterns and formula that showed how the universe interconnects on a physical and spiritual level (everyone gets those, right?), I had an epiphany: I've already written most of an Authorization as a Service (AzaaS) solution.
I define Authorization as a Service as: A service able to correlate identity, context and operational facts with a rule-driven policy, produce a decision for an authorized claimant, provide a simple API to assert authorization, and optionally export entitlement and authorization policies back to identity and enforcement systems.
Many Enterprise Service Bus (ESB) products such as Layer 7 or IBM DataPower include XACML processing engines that, when included with Policy Information Point (PIP) configurations, meet this definition. And, a number of token implementations, particularly for OAuth, include framework features, such as for access policies, that also meet this definition. Business Process Management and Business Rules Management systems (BPM and BRM respectively) provide industrial strength process and rules management that are able to capture and articulate complex business workflows, and, in part, meet this definition. So, why are products like Layer 7 and BPM, or entitlement and token formats like XACML and OAuth, or BPM and BRM systems not all billing themselves as AzaaS?
If one of my customers asked for an AzaaS solution, I'm not sure what I could sell them because I have not yet found a product or service offering that meets these challenges.
Providing Identity as a Service is hard enough. There is a veritable mountain of data needed to describe a person, their myriad accounts, and the policies and rules governing those accounts. One additional challenge is an IdaaS must logically separate organization data, or the vendor must operate multiple cloud instances on a per-organization basis. Authorization as a Service shares that challenge. Another challenge is data sensitivity and protection. Authorization rules may need to digest sensitive information that must otherwise remain protected, and storing pan-organization sensitive data ranges from being undesirable right up to being illegal, depending on the location and the type of data. A third challenge is being able to cache the large volumes of identity and account data, in addition to and related with, but decoupled from, rules data. A fourth challenge is being able to represent the different ways organizations and their applications describe entitlements. Technically, these challenges could be me with XACML, PIPs, and a nightmarish configuration, or with OAuth and a framework and a lot of hand-rolling of code. My concern with either of those would be that any AzaaS solution is driven from an entitlement or token format.
Fixing an IdM Challenge
Identity Management (IdM) platforms tend to take a myopic view of entitlements. They define roles, and map roles to entitlements, and evaluate the effective entitlements from the role hierarchy, but roles are only meaningful in a given context; A role in an IdM system only means something in that IdM system. That role doesn't mean anything to a managed application, even if that application defines its own role with the same name, because that application role is usually treated as an entitlement to the IdM system. Also, there is many organizations struggle to architect roles with respect to how roles differ between organization, business, and application, and it's no wonder that role-based access control (RBAC) is so difficult to implement, and why customers gravitate towards attribute-based access control (ABAC). In some cases, organizations that don't use RBAC are already using ABAC without realizing it. Not that that makes configuring the IdM system any easier.
While working through such a challenge, I created a proof of concept (POC) based on my Account Manager 5 and Rocket libraries. Account Manager 5 is a multi-organizational data and directory library. Rocket is set of schema and services that extend Account Manager for use as an object-oriented project management library. The POC integrated with a specific vendor's IdM product, and, in this case, the solution required ingesting multiple views of the same IdM person, application, account, entitlement, role, and attribute data, something that Account Manager and Rocket could already do.
Identities in Bulk
I wrote Account Manager to be a drop-in library for enterprise applications, but use it for less enterprise-y activities like sifting through my photos. One of the first demonstration applications I wrote over ten years ago was a JEE application for navigating through my digital photographs from a Web browser. Over time, as I rewrote the library from Java to .NET to Java again, I got tired of exporting and importing the database, and transforming data around schema changes. Also, as the authorization features become more complex and the object model more normalized, adding one new object could result in several database operations.�To make this more manageable, I added bulk factories that applications use to build up complex object relationships with security configurations, including id references, before actually adding the objects from the database or generating the id. The Bulk Session capability allows for rapidly persisting all types of objects and dependencies into the database.
While creating the IdM POC, I created a set of integration tests that would delete and reload bulk sets of identity data into Rocket projects. This allowed me to replicate the entitlements evaluation of several enterprise IdM solutions N number of times, for N number of organizations.
Over the years, I've been plinking away at a rules evaluation process and have never had a reason to codify it as an extension.�There are already many rules systems out there, so there is no point in reinventing that wheel, except to be more tightly integrated and more direct data-level access. Thinking about an AzaaS solution, or rather, dreaming about one, I realized that if I redefined these rules to function principally for an authorization service, would have a library that could reasonably serve as an AzaaS solution.
The following are features of my AzaaS solution.
The only parts I need to add from the existing libraries are extensions to the authorization service to accommodate a lightweight rules and policy mechanism, and then exposing an API to invoke the policy. The rest of the system is composed of CentOS, JBoss, and PostgreSQL.
While in our cute little Laguna Beach rental cottage, I found a dog-friendly house rental next to Buena Vista park. The owner and I exchanged a few emails and the lease was set. But, something odd about the owner's address struck me. It was on the same street, and very similar to the house number of my co-worker, J. I double-checked J.'s address, and it turned out the rental property was owned by his neighbor. Small world.
J. was a quirky guy, an absolute maven at sales in a manic sort of way. He gravitated towards the technical side of security jobs, even though he had this uncanny knack for resource placement. He should have been in sales; He should have been a recruiter; He should have run his own consulting firm. He would have been a rock star in any one of those fields. J. couldn't swing the pure technical side by himself, though, which is how I had been roped into my current job, which had afforded me the ability to work out of Laguna Beach, and which now brought me to a rental house in San Francisco that, by pure coincidence alone, was owned by his neighbor. And for all of J.'s idiosyncrasies, and he was a very unique fellow, he played the straight man to his neighbor (and being so near Castro, I have to emphasize this as being the non-Castro version of straight).
We arrived at the rental late Sunday afternoon, rain freely falling as it had in Snoqualmie, Washington, and just as chilly. Multi-million dollar homes with gorgeous views of the city lined the street, and sandwiched between them listed our little rental. A large white sign, protected by a sheaf of tattered plastic, decorated a wooden stake in the front yard, where it had stood the test of time for at least, according to the owner, ten years. Was the house condemned or something? No, couldn't be. Was this the right address? Yes. We met with the owner, a thoughtful host who had come straight from the nineteen sixties to meet us, and then apparently returned because we never saw him again. While in the present, he toured us around the rental portion of the property, which included the front door and the first floor of the house.
Not covered by the rental were the driveway, which would have been nice to park in, or the back yard jungle, which would have been nice for the dogs, or the lower floors. The restriction wasn't due to privacy, so he claimed, though Anne and I wondered what secrets lurked below. Although tempted to explore the secrets lurking below, safety was the pragmatic reason for limiting access. While the view from the back of the house was stellar, a million dollar view if there ever was one, that view was supported by some moldy two-by-fours that caused the entire back half of the house to sway whenever we both stood near the window. The first night, we lay awake and Anne wondered if the house would collapse under us at any moment. I consoled her with the knowledge that the owner said the house wasn't condemned, it was just scheduled to be demolished. Difference.
Living in a soon-to-be demolished house, soon being any point the moment we left, came with a set of benefits and quirks. For starters, the furniture was draped in blankets and bedspreads, and we could let the dogs have their way with the wood floor. And boy did they like tearing back and forth across that every time someone walked their dog by the front window which, as it turned out, was twenty-four hours a day. On the other hand, I made little discoveries like the bathroom door knob falling off in my hand when I tried to open the door from the inside, and then having to fuss with the lock to get back out.
Anne and I had been to San Francisco together before, and separately on a number of prior occasions. All of those previous visits went well, and overall San Francisco showed us its gilded side. This time, however, the city rolled over and smothered us with its mangy underbelly. Were it not for our respective friends and coworkers, it probably would have been a wholly miserably experience instead of a mostly miserable experience. Keep in mind our plan was to get some California sun while working remote. This particularly week, it never made it past fifty degrees, and the rain never let up except to part for a little shindig going on in the nearby Castro district because, let's face it, there were far too many rainbows and too much sunshine coming out of Castro for a drop of rain to ever touch the ground.
We took the dogs on a walk around Buena Vista Park, and right away the seedy underbelly infused us with its mongrel stench. It was dark, rainy, the sidewalks and street covered in litter, and shadows emerging from the unlit paths and sidewalks never seemed overly friendly. Of course, the few people we did meet were very nice, but, still, we couldn't shake that feeling. Well, more accurately, the feeling bounced from Anne over to me, because we started the walk with Anne being somewhat worried, and ended with her feeling relieved that they were only leering at me.
We braved the cool rain for few outings, such as walking to the nearest market to tote some groceries back to the rental, and then take a stroll down the street to a little park. Otherwise, the remainder of the week passed under a curtain of rain and cold.
On Wednesday, we met H., one of Anne's former co-workers and friends, and he regaled us with the life and times of a successful software engineer. Listening to him talk excitedly about work and all of the possibilities, replete with the HTT air, took me back over fifteen years to when I first worked at Microsoft and enjoyed my own slice of excitement and success. Granted, it wasn't the buffet style success many associate with high tech, more like a tapas portion. Nonetheless, it was invigorating to hear H. talk and share his stories with us. On Thursday, Anne took the day to visit a customer, and my coworker J. took me on an early morning coffee run that afforded us a chance to let the dogs spelunk around on the beach. The weather sucked, but it was nice for everyone to get out for a bit, rain or no. Sunny and Coco were right at home on the beach, even if it was cold and windy as sin and they wound up getting covered in sea foam, sea weed, and wet sand. J. and I worked out of his house that day, with Sunny and Coco leaving sandy footprints everywhere they stepped; J.'s house was a great pet-friendly working environment.
Thursday night, Anne had the car and I was alone at the rental with the dogs. I ordered a deep dish Chicago-style pizza that took an hour and a half to deliver and weighed a metric tone. Although the astroturfers on Yelp had rated it four stars, it was more like two and a half, but on a rainy and cold March evening, it actually tasted - no, no in retrospect it still tasted pretty bland.
And that's how the week ended, in a chilly torrent of rain. We discussed going back to Laguna Beach, and I know Anne wanted to go, but by then I was somewhat burned out on the back-and-forth, and missed my creature comforts back at the house. Besides, our house wasn't exactly prepped for a long excursion. I suppose it would have been different if I had prepared a little bit more.
We put everything into the car and drove home in a single day. This wasn't the first time we had driven from San Francisco to Snoqualmie in a day, and it wouldn't be the last. I don't know what primal force compels me to make the drive from San Francisco to Seattle in a single day. I have no problem taking my time going south, but going north my brain hones in on the destination and I don't really want to drag it out any longer than needed. And, after each trip, I wonder what the heck I was thinking. I think this is inherited behavior from my father, whose idea of a road trip was to run a forty-gallon tank down to the fumes before calling for a bathroom break. Using early 1980's fuel economy regulations, which, lets face it, allowed us spew a figurative ton of carbon into the air, that comes out to be about five hundred miles. Nine hours of driving without stopping. I'm sure that happened only once or twice a trip, because I have strong recall of stopping when the car broke down too. But, then, it wouldn't have been genuinely Made-in-America if something didn't break.
By the time I passed Medford I just don't want to stop. Maybe Oregon is somehow unidirectional. I just don't know. Our adventure in California ended after a little over three weeks, and it seemed like the iron to pull a similar stunt was cooling off and the opportunity slipping behind us.
Then again, hadn't we made that opportunity for ourselves in the first place? Couldn't we make it again?
Driving home, I wore my birthday present from my MIL, a shirt and sweater vest. For some reason, I was compelled to document the journey of this present, and took pictures of it at each stop before finally opening it in San Francisco. My attempt at Garden Gnome vacation slides, I suppose, except the present never made it to anywhere more exotic than sitting atop my duffel bag.
Recently, Anne and I met H. again for a follow-up, the last time we met being in San Francisco. Although the march of time had smoothed down some of H.'s expectations, he nonetheless exuded infectious optimism. I also received a note from a work acquaintance suggesting I call J.s wife, N. It turns out J. had passed away. Maybe. J. is such a unique character that part of me wonders if he isn't still out there somewhere. Probably working at the NSA.
We made it back home around midnight. Sunny and Coco were curled up together on the back seat, so there was that.