Background

A few months ago, just as summer was getting underway, I had the privilege and honor to speak at Identiverse on the latest trends in authorization (you can watch a recording here and you can glance through the slides here). The talk served as an update to an article I had written in 2018 on the state of authorization. While there is a clear consensus on what authentication is and does, the waters are a little muddier when it comes to authorization. What is it? Where does it begin? End? And why is it so hard to pin down? What are the current efforts in the standards community and the industry to address authorization? This article aims to address these points.

Defining Authorization

One of the problems with authorization is that it can be used to describe many needs and technologies. The term itself is abused. Think for instance about HTTP 401 Unauthorized. Does it mean you didn’t have the right authorization? No, it means your authentication failed. So, why is it called unauthorized? Just a misnomer. Similarly, OAuth stands for Open Authorization. Yet OAuth is mainly about access delegation (I grant a given service X controlled access to my data on another service Y) and addressing the password anti-pattern. So let’s level-set here and define what authorization truly is in the broadest possible sense:

“Authorization is about granting or denying an entity access to another entity.”

In the presentation I gave in June, I wrote that:

• Authentication confirms that users are who they say they are. 
• Authorization gives those users permission to access a resource.

More broadly, authentication is about proving a claim about someone or something. Usually it’s a person’s identity. But it could also be an attribute of that person e.g. their date of birth.

Authorization is the process of granting (or denying) someone or something access to something else. Authorization needs to consider what we know about the requestor and the requested item before granting access.

The challenge is that over the past 15 years there hasn’t been one major model, standard, or framework to address authorization. Unlike SAML which has tackled SSO, there hasn’t been one turnkey solution yet. But The Times They Are a-Changin’ and it’s time to revisit the space.

Requirements for an Authorization Framework

Before we look into existing solutions, let’s look into requirements. Basic ones aside (e.g. consistency or performance), there are three fundamental requirements any authorization model or framework should address:

1. Configurable: you need to be able to change your authorization without having to code your application from scratch. It should be possible to reuse the same framework from one application to another.
2. Future-proof: your authorization framework should be capable of adapting to new requirements. If a new legislation or business need comes into play (e.g. GDPR) then the authorization framework should be able to adapt.
3. Auditable: your authorization configuration (artifacts) should be understandable by the audit teams. Humans should be able to ask both (a) what did happen and (b) what can or may happen.

In addition, authorization needs to reach out from the identity realm to extend to other dimensions. One issue with models like RBAC or standards like OAuth is that they are all identity-centric. Yet, an effective authorization solution needs to consider not only the requestor’s identity but also the targeted resource and its attributes as well as the context of the interaction. This leads us to the Venn diagram of Authorization:

Authorization, properly defined, should reside at the intersection of all three dimensions: identity, entity, and context.

Types of Authorization

I’m often asked what the different kinds of authorization are. I usually break things down into three categories:

• Functional authorization: you could ask whether a user, as a whole, can print. This is fundamental when generating scopes, claims, or maybe just rendering a UI.
• Transactional authorization: can a specific user do a specific action on a specific item e.g. can Alice view account 123? This is nearly always a yes/no (binary) question. Transactional authorization typically occurs in API calls or business processes.
• Data-centric authorization: sometimes you want to select an entire swath of data (an unknown number of items) and asking yes/no questions is either not possible (for we don’t know what there is) or doesn’t scale (for there are millions of records). In that case, we need an authorization framework capable of reversing queries (flip questions). This is data-centric authorization. Data-centric authorization occurs when retrieving data from databases or Big Data systems (anything from traditional RDBMs to systems like Snowflake). To do so, your authorization language’s syntax needs to be ‘reversible’. Lea Kissner of Twitter calls it reverse-indexable. Axiomatics’ Chief Product Officer, Pablo Giambiagi calls it Reverse Query. And OPA’s co-founder, Torin Sandall calls it partial evaluation.

Who Defines Authorization?

There are two main sources for authorization:

1. The resource or data owner: I, the owner of the data, decide who can access my data. This is exactly the sort of authorization that takes place when I share a Google Doc with a coworker.
2. The enterprise: as the data steward and the owner of the services, the enterprise can determine who can access which services and data. In the previous example, my employer can choose to add authorization checks. For instance, the employee can only share with other employees but not outside the enterprise. Note that the enterprise might have different drivers such as legal, compliance, or merely business.

When do we Enforce Authorization?

There are two ways authorization can be enforced:

1. At design-time: in traditional identity-centric authorization models, authorization is usually defined when the user is defined, created, or updated. We assign those users groups, roles, and permissions either directly or via profiles. The rest of the authorization is devolved to the application code.
2. At runtime: if we are to consider contextual information e.g. time of day or a requestor’s geolocation and if the authorization is to be decoupled from the application, then it is necessary to enforce authorization at runtime.

Now that we’ve looked at the requirements and traits of a comprehensive authorization framework, let’s discuss existing approaches.

The Current State of the Art

Models, Standards, and Frameworks

When authorization is being discussed things like RBAC, ABAC, XACML, and OPA come to mind. These are not all equal and it’s worth grouping them into one of three categories:

• Model: abstract approach to implementing authorization e.g. ACL, RBAC, and ABAC
• Standard: a formally approved set of specifications that define how to address authorization e.g. SAML, XACML, OAuth…
• Framework: a technical implementation that handles authorization without being a standard itself e.g. Ruby cancancan, OPA, or Oso’s Polar.

With this in mind, let’s charter the land of authorization. In my Identiverse presentation, I came up with the following (incomplete) diagram and timeline.

Models

In the first category, we have 3 main models: ACL, RBAC, and ABAC. There are occasionally other acronyms that pop up e.g. PBAC, GBAC, or ReBAC (policy-based, graph-based and relationship-based) but these tend to be analogous to ABAC.

While ACLs can be extremely fine-grained (to the point of assigning a specific user to a specific item), it is usually too tightly coupled with the applications you want to protect and its management does not scale well.

RBAC addresses the management scale issues of ACLs but, given it is identity-centric, falls short of allowing for contextual, runtime authorization.

ABAC addresses the limitations of RBAC and introduces policies as a means to define authorization rather than roles. However, the governance becomes more arduous. Most of the latest innovations in authorization (Authzed, Oso HQ, Open Policy Agent, and ALFA) are all to some degree ABAC. They use a policy language (or in Authzed’s case a schema language on top of Zanzibar’s configuration language) to express authorization.

ABAC Architecture

The following diagram summarizes ABAC’s architecture and flow.

• PEP: Policy Enforcement Point: this is how applications are integrated into the ABAC architecture. Example PEPs include API gateways, annotations, and proxies
• PDP: Policy Decision Point (the “engine”): the PDP evaluates policies and generates decisions
• PIP: Policy Information Point. PIPs allow the PDP to query data sources for attribute values
• PAP: Policy Administration Point where policies are managed (defined, governed, audited…)

Standards

Identity-derived Standards (RBAC)

SAML, OAuth, and all its derivatives such as UMA, GNAP, Rich Authorization Requests (RAR), and JWT access tokens do tackle authorization to some degree. But, as noted previously, they are identity-centric and leave out the context part. Additionally, they are not policy-driven which means they can be harder to manage.

That being said, User-Managed Access (UMA) does fill the authorization gap around consent management. UMA can be used to collect a data owner’s wishes. That information can then be used in other standards and frameworks (e.g. XACML or ALFA).

Rich Authorization Requests (RAR) are also a bridge between the identity side and the authorization side. With RAR, full authorization decisions can be delegated to a decision engine (e.g. a Policy Decision Point).

JWT AT can also be used as the bearer of authorization decisions inside of the access token and as the source of attributes or claims to be used in an authorization decision.

Alone, these standards will suffer from the same woes RBAC suffers from. But used in conjunction with ABAC approaches, they become invaluable.

Standards that Implement ABAC

There are 2 official standards that implement ABAC today: XACML and ALFA. XACML (the eXtensible Access Control Markup Language) has been around since 2001 and is to authorization what SAML is to federation and SSO. They are both part of OASIS’ family of standards. XACML has had some success especially in the era of XML gateways (in the pre API days) but its syntax (XML-based) has made it hard on developers.

ALFA (the Abbreviated Language for Authorization) addresses the syntax aspect of XACML. It is easier for developers to write in ALFA.

XACML and ALFA still lack massive adoption and part of the challenge is that both languages (which are interoperable) are too generic, too broad. This makes it harder on developers and business users. Additionally, XACML and ALFA require that attributes be defined. This is true of any ABAC-like system and it adds an extra burden on the framework adopters. What are those attributes? Who defines them? Who governs them? How are their values retrieved? This is where RBAC is simpler: all attributes are identity attributes and are stored in the “one and only” identity store.

Beyond Standards, Authorization Frameworks Abound

I’d like to start this section with this little xkcd cartoon. When there are too many standards, define a new one. This is, in a way, what’s happened in the past 5 years. In spite of XACML and ALFA, we have seen the rise of Open Policy Agent and its language Rego as well as Oso HQ and its language Polar. Google released Zanzibar (a framework to manage permissions at scale) and several companies (Authzed and Auth0 to name a couple) are building management solutions on top of Zanzibar.

Open Policy Agent

Although I peg them as a framework, they could be considered as a standard given they are part of the CNCF family. OPA follows the same architecture as XACML and ALFA. OPA has a large ecosystem of enforcement points making it easy to adopt OPA especially in the Kubernetes and microservices world. The language, Rego, is based on Datalog. Its syntax is simple enough that it can be handwritten by a developer. However it lacks the scaffolding and structure that come with ALFA or XACML. In addition, Rego can do data manipulation which can be both a good thing and a bad one as it blurs the lines between what should be in a policy (the rules) and what shouldn’t (the data massaging). There are several companies such as Styra who aim to address the management aspect of OPA and Rego.

Oso’s Polar

The Oso authorization library uses the Polar programming language to express authorization logic and policies. Like XACML and ALFA, it is a purely declarative language. Polar combines together the definition of facts e.g. 

# father(x, y) ⇒ y is the father of x.

father(“Artemis”, “Zeus”);

With rules e.g.

allow(“Zora”, “read”, “document-1”) if 1 = 0;

Because Polar mixes both the definition of the model through relationships and the definition of the authorization rules, it steps a little bit outside the boundaries of ABAC and into “ReBAC”. Graph-based authorization models go down that path as well. In the long run, it might make it harder to manage such policies.

Zanzibar

Zanzibar provides a uniform data model and configuration language for expressing a wide range of access control policies from hundreds of client services at Google, including Calendar, Cloud, Drive, Maps, Photos, and YouTube. (source). Zanzibar is still ultimately ACL-based. It stores access control lists (ACLs) and performs authorization checks based on those stored ACLs. It acts as a framework on top of ACLs across all of Google’s services (originally). Zanzibar’s goals were not (originally) fine-grained authorization as defined in NIST’s ABAC. Rather, Zanzibar’s goal is to make sure authorization is consistently defined and coherently enforced across all of Google’s distributed services at scale.

From a ‘language’ perspective, Zanzibar uses namespaces, relations, usersets, and tuples. It also muddies the waters between what is truly policy (A user can do X) and definitions (A is the father of B).

Conclusion

The authorization world is growing faster than ever: the # of new startups is a homage to its vibrance. Yes, it pains me to write as such but XACML’s XML syntax is dead. However, in good old Monty Python “I’m not dead yet” fashion, XACML isn’t. In fact, XACML, ALFA, and OPA are essentially variations of the same model, ABAC. Graph-based approaches such as Nulli’s, Oso’s Polar, or Authzed are worth keeping an eye on. I like to keep things clean and as such I prefer ALFA (but I’m also biased). Application and infrastructure vendors (Azure, AWS, SaaS, app frameworks) will keep offering their own approaches. AWS’s IAM is a great example of ABAC using tags and policies (attached to users, objects).

What matters above all else is the ability to easily author, manage, enforce, and audit your policies. This might mean that the true answer to authorization may not so much reside in a single standard or language. It might well reside in the governance layer. And in that space, it may be worth looking into the Identity Query Language (IDQL), a new standard for identity and access policy orchestration across distributed and multi-cloud environments. My former colleague and friend, Gerry Gebel (Strata) spoke on that very topic at the European Identity Conference this past September.

And since you made it this far…

Does it have to be a standard? That’s a good question and I think the short answer is no. There are always benefits to standards (avoid vendor lock-in). In IAM, the biggest benefit has been interoperability. In my role at Salesforce, I am grateful for SAML and OpenID Connect as it makes it easy to integrate Salesforce with many identity providers. But when it comes to authorization, the need for interoperability is not as important. What the policies are written in does not impact how an app is integrated with the policy engine. The need for interoperability is therefore on the request/response side only. Make sure you choose a framework or standard that has a rich ecosystem of integrations. OPA and ALFA both provide integrations.

Additional Resources

• Authorization in software – an Auth0-curated podcast
• Identity Unlocked – a podcast by Vittorio Bertocci
• Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• Role Based Access Control
• OASIS XACML
• ALFA – Abbreviated Language for Authorization
• Open Policy Agent’s Rego
• OSO HQ’s Polar authorization language
• ABAC for AWS
• Ping Identity’s Essential OAuth Primer
• Authzed Demo
• Zanzibar: Google’s Consistent, Global Authorization System
• Authorization is the next big technical challenge

The post The State of the Union of Authorization appeared first on IDPro.

But here in 2019, we’re really starting to see the edges of what OAuth is good at. There have been many extensions to OAuth 2.0, some of which protect specific parts of the process like PKCE for mobile apps, JAR/JARM for front channel protections, and PoP/MTLS for token presentation. Other extensions have added new ways to do OAuth, such as the device flow and CIBA. The prevalence of such extensions speaks to OAuth’s flexibility, but the landscape is getting harder for developers to navigate. New styles of client and server deployment, new security threats, and new expectations from both end-users and developers have all pushed the OAuth framework into spaces it was never designed for, and the results can be overwhelming. In the last few years, I’ve been looking at this landscape of options and attempting to draw out some of the commonalities of the various OAuth 2.0 extensions into a new abstraction that learns the lessons of OAuth 2 without carrying its hard-earned baggage.

Some of OAuth’s biggest problems come from its overuse of the front channel for passing essential security information. While front-channel redirects are an essential innovation in allowing interactive user consent, the way OAuth 2 uses these redirects leaves it open to a variety of alteration, injection, and data leakage attacks. But this begs the question: does the protocol need to put all of that information into the redirects in the first place? We can get around it by using the “Intent Registration” protocol design pattern. If the client makes a back-channel call directly to the authorization server first, all of the sensitive information for the authorization request can be passed directly between the client and the AS without going through the browser. The AS can return a reference that the client can pass to the browser that represents the sensitive information, instead of carrying the information itself.

This step creates a transaction between the client and authorization server which can be augmented, mutated, and adapted over time as new information is made available and decisions are made. If the AS decides from this first call that it doesn’t need to talk to the user, then it can return an access token immediately. If it instead decides that interaction is needed, the client and AS can signal to each other the ways that the interaction can take place. In OAuth 2, each of these paths has to be managed and chosen up front through selecting the grant type, response type, scopes, and extensions to the OAuth 2 protocol in play.

Since we’re pushing information upfront, this transactional approach gives us a chance to describe resources more richly than OAuth’s scope strings allow us. We also have a chance for the client to present and bind keys to the transaction, allowing a stronger association with the client software even when using ephemeral keys with mobile applications and single-page apps. Instead of basing all of our trust on a pre-registered client system, which is what OAuth 2 is optimized for, we have the ability to base our trust on a variety of policy mechanisms that fit different types of applications much better.

Finally, we have an opportunity to use these patterns and capabilities in a space beyond authorization delegation. For example, let’s say you have a process where most of the time you want your API calls to function without hindrance, but once in a while, you need to interact with the user to get additional information, like an updated credit card number. This transactional pattern allows us to rethink how we approach authorization and access to our APIs.

The XYZ project (with information available at https://oauth.xyz/) is a concrete proposal for how we could do all of these things in a new protocol that is based on the concepts of, but not compatible with, OAuth 2.0. I’ve presented XYZ at the Identiverse Conference (https://www.youtube.com/watch?v=U9i7YaN8v9c) and the IETF OAuth Working Group (https://www.youtube.com/watch?v=TE3Fzb5-Jz0&t=3764), and the conversation is starting to pick up in the IETF with the TXAuth mailing list (https://www.ietf.org/mailman/listinfo/txauth).

The IETF will be discussing this at the TXAuth BoF session in Singapore on Monday, November 18, 2019. You can participate remotely via the links for TXAuth at https://datatracker.ietf.org/meeting/agenda/#txauth.

Justin Richer
Bespoke Engineering LLC

The post Moving Beyond OAuth 2 With Transactional Authorization appeared first on IDPro.

Cast of Characters

        (In Order of Appearance)

Narrator/Inquisitor:                                                           George Dobbs

Rey:                                                                                 Marc Boorshtein

Kylo Ren:                                                                             Mike Kiser

          Yoda^*: James Dodds

Lando Calrissian:                                                                 Jonathan Sander

Luke Skywalker:                                                                   Jeff Lombardo

Finn/Poe Dameron/BB-8/Unnamed Bot:                               Matt Topper

*Character not appearing in this film

Thematic visuals for “research purposes”: https://www.youtube.com/watch?v=adzYW5DZoWs

Open to a black background, devoid of light or substance. The sound of heavy breathing, as if someone had just run a marathon after only training for a local 5K race. Proprietary logo reveals itself in an expensive Adobe after effect (may be out of current budget for this project.)

George / Narrator speaks slowly, with a rich, auto-tuned voice. Think James Earl Jones, but significantly more majestic.

George Dobbs / Narrator: What kind of entity is a robot?  Large enterprises seem to be on a phase of adopting “Robotic Process Automation”. This adds a layer to existing application sets by having a “robot” pretend to be a human that has access to the set of applications. The robot is a form of script that does a well-defined business process repeatedly. Unlike other types of integration this requires accounts that look a lot like human accounts, but are run automatically. Recently my company has decided that these should not be treated like humans – as in there should be no HR record. This leads me to IDPro to ask this group – are there “best practices”? My immediate concern is around the creation of the record for the instance of the robot, so we can send it to the credential system, to get the access rights started. If not done in the HR system, where are others seeing this handled?

Fade up to a breathless Marc / Rey, scanning desert planet. It’s not Tatooine, at least according to J.J. Abrams.

Jeff Lombardo / Luke Skywalker: (Mysteriously and emphatically, just like you would expect a force ghost to speak; almost as if you had interrupted a vaguely important phone call.) We’ve passed on all we know. A thousand generations live in you now. But this is your fight.

Fade to black. White text fades in:

EVERY GENERATION HAS A LEGEND

. . .then fades rapidly back to black.

In the distance, a glowing speck on the horizon shimmers in the desert heat. You know it’s some kind of craft because you’ve seen this kind of movie before.

Marc Boorshtein / Rey: (Quietly, but firmly) Why not treat them as service accounts?

Jump cut to interior of the approaching ship. Camera focuses in on the gloved hands steering. No face, no other identifying marks, just rich, Corinthian leather promoting grip and control of the craft. A voice, presumably of the pilot, echoes metallically in the cockpit.

Mike Kiser / Kylo Ren: (Angry, but subdued) You could, I suppose, but I generally advocate treating them like contractors which means no HR, no benefits, but you DO need an authoritative repo for them. Then you can limit / track them like you would a contractor. (keep in mind that a contractor repo would be separate from this as well). There are a couple of reasons for this:

1)           they are replacing contractors, or potentially are

2)           they have some level of intrinsic access, which may involve access across apps

3)           contractor model reminds of the need to make everything time limited: entitlement, life cycle, carts, etc. You lose some of that tracking etc. with pure account model. 

James Dodds / Yoda: (Sagelly jumbling grammar): Recognize bots as new identity type you will, because it is important to differentiate bots from the rest of the worker population; bots do not need compliance training, to enter timesheets, get paid or have access to benefit plans. Have data consumers opt-in to bot data only if needed.

Marc Boorshtein / Rey: (Emotionally fragile, but firm) Not sure I agree. Assuming you have a process for creating and tracking service accounts you will need the same thing in this instance. Then the account’s ownership can be delegated to someone responsible. Someone will need to be responsible for the “robot”. And if you don’t have a process for managing service accounts then this would be a good time to create one. 

James Dodds / Yoda: Always two there are, no more, no less. A master and an apprentice. Both service and bot are nonhuman – difference is the privilege of the bot

Mike Kiser / Kylo Ren: (Angrily) Completely agree with oversight. I do think that the model needs room to expand beyond a simple account, though, to express the agency that bots / RPA have.  Also agree with needing a solid service account approach as well I think the contractor model also can encourage that oversight – by placing it more appropriately within the org.  With service accounts, for instance, there is always a danger of dumping them all under one overseer. That issue still exists with bots as contractors as well, of course ….

James Dodds / Yoda: Adventure. Excitement. A bot craves not these things, yet must access many things. Service and bot are nonhuman at core and may share the same birth.

Marc Boorshtein / Rey: I think we are saying mostly the same thing. It’s more about the process then the tech.

Marc spins rapidly, igniting his pale blue lightsaber, and crouches as he stares down the insanely rapid approach of the TIE Silencer.

Mike Kiser / Kylo Ren: (Rapidly and angrily) Agreed – I’m open to discussion. Another neglected side of bots is discovery in the first place – lots of innovation / independent adoption going on without notification of the identity program.

Marc / Rey breaks into a sprint as Mike / Kylo Ren overtakes him, certain to obliterate him as only a large metal object moving at ludicrous speed on a desert planet can.

Fade to black. White text fades in:

THIS CHRISTMAS

. . .then fades rapidly back to black.

[Note that this scene is not seasonally dependent.]

Marc Boorshtein / Rey: I think ultimately a service account should be treated like a regular account with one exception. There’s someone or a group responsible and accountable. Your robot needs access to an API? The responsible person requests access to that API on the service account’s behalf.  Well, I think lack of integration of Enterprise identity has much more to do with the difficulty of getting resources and agility out of most Enterprise identity teams. 

Marc leaps, unnecessarily, off of his back foot, and spins into the air. With apologies to Douglas Adams, he hangs in empty space much in the same way that bricks don’t. He is now at about eye level with the pilot, and enters the expected slow motion to make sure that the producers get the maximum value out of their special effects team.

Mike Kiser / Kylo Ren: (Angrily surprised) I would mean to use PAM for service accounts and then have the bots go through PAM process to get access as needed.

Marc Boorshtein / Rey: Potentially. Not sure I’d want to go through a PAM process for everything a bot may need. But I’m sure some things deserve that level of scrutiny. 

James Dodds / Yoda: When you look at the bot side, careful you must be. For the bot side looks back. Controls apply to the privilege granted, not the type of account.

Mike Kiser / Kylo Ren: (Accelerating angrily) Likely depends on the use case, as always. Guidelines are suggestions until you actually understand the circumstance.

Marc, blatantly continuing to deny the reality of gravity on this arid planet (but to be fair, we’re not really given its mass, so maybe it is completely realistic), continues his rapid rise. He is now upside down, facing the oncoming transparent cockpit, ready to use his weapon which historically would not be useful for high-velocity combat.

Marc Boorshtein / Rey: Agreed

Cut to black. Fade up on a mysterious dark planet. It is night, clouds mysteriously obscure much of the view. Lights twinkle in an opulent landscape, which beckons to the viewer but is shrouded in mystery. What is potentially an A-Wing zooms past cliffs and jagged peaks and descends towards the city. Mysteriously.

Narrator (George Dobbs) still speaks slowly, with a rich, auto-tuned voice. He’s left the James Earl Jones vibe behind, and is rapidly approaching what can only be described as “Morgan Freeman in a Nature Documentary.”

George Dobbs / Narrator: Thanks for the discussion. A little more background. Today it is handled like contractors. Contractors are passed into the HR system so they get treated like EE’s (mostly) for things like org charts and access control. One odd thing is that the robots now end up in the org charts. Ha! My initial concerns are extending SoD to the robot “owners” and managing the owners as they come and go.

James Dodds / Yoda: Simple classification will keep the bots in their place. So certain were you. Go back and closer you must look.

George Dobbs / Narrator: One thing that is different with these accounts is they have to handle the password rotation exercises and somehow fudge any MFA setup. The ideal solution would not allow the robot operators to inspect the credentials.

George Dobbs / Narrator: So, my sense is similar to service accounts but not identical.

Marc Boorshtein / Rey: Yes. Thing is, you need to have the management of account owners regardless (at least until the machines take over and then the management issue is solved).

George Dobbs / Narrator: Right, then we just flip it on its side and the machines manage us! 

Marc Boorshtein / Rey: Agree on the human owner not knowing the creds. Whether it’s something like Vault/Conjur or Spire some kind of short-lived one-use token is needed for robots. That way you manage the risk of it becoming a vulnerability. Ah, what bliss that will be! Although knowing my luck I’ll be stuck in meetings with cyborg executive officers explaining for the 10 millionth time that storing a password as clear text in a database table is a terrible idea. 

Jump cut (again) to Jonathan / Lando sitting beside Chewbacca in the Millennium Falcon. They jump to lightspeed as Jonathan / Lando laughs, handsomely.

Jonathan Sander / Lando Calrissian: (Cachinnating confidently, without a care in the world but certainly not without a thesaurus) Many of our customers have “bots” and “service accounts” (both ill-defined terms/concepts in my mind), and the strategies to manage them vary to a degree almost equal to the number of them I’ve spoken to about it. One thing they all have in common, though, is the agreement that the biggest difference between service accounts and bot accounts is that service accounts do things on behalf of a thing and bots do things on behalf of a person. That specific idea does often clarify which roads they ought to go down in whatever internal processes they may already have. My bots do things for me. The department’s service accounts do things the department needs to have done. The latter is diffuse accountability and responsibility while the former is very specific. And this typically implies a great deal of delegation discussion – which for us has driven all the requirements for our OAuth 2.0 rollout.

George Dobbs / Narrator: If HR dept. owns records for employee-humans, and Procurement dept. owns records for contractor-humans, who owns records for so-called robots? 

James Dodds / Yoda: Difficult to see. Always in motion is the future nonhuman id. Judge me by my size, do you? <Kick into the air>

Jeff Lombardo / Luke Skywalker: (Speaking from everywhere and nowhere at the same time) Ops? DevSecOps (for what that means)? RPA is just the grand-child of Automated Testing being used for more than just fuzzing the UI with random data. Now we are fuzzing intelligible and legit data as part of a workflow, event, scheduled tasks.

Cut to Finn and Poe as they stare out from a rock outcropping. Poe stands behind Finn from an elevated position. The framing for the shot is perfect, as if they are about to release their first studio album together as the world’s smallest boy band.

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Finn) I’m still struggling with why bots aren’t treated like service accounts. If service accounts are doing things on behalf of an application that application still has an owner responsible for the access. I don’t see how a bot account is any different. In most cases these bots are recorded, fed data and executed on a centralized server not locally on each person’s machine

Rapid fade to shot of Matt (BB-8) and also Matt (“Unnamed Bot.”) Both droids (bots) are completely unaware that the entire movie has centered around how to govern them appropriately.

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: As BB-8 and Unnamed Bot, slowly cock heads to one side)  . . .

Cut to Marc/Rey, staring across a tempestuous sea, with the remains of what looks to be a death star on the horizon.

Jeff Lombardo / Luke Skywalker: (Larger now, as if he has stepped into a large, empty public theater before the Hamilton rehearsal starts) Employees are processed from HR because they are paid and we know they will stop being paid as soon as necessary. So, we delegated the risk to people who actually care. We also do that because we need to reflect on promotion (demotion), and lateral movement in the organization. Again, we delegate our burden on entitlements to those same people who care(and sometimes their managers). Same applies to contractors, but because it is contractually bound (payments and scopes). Here’s why scope changes with contractors. Robots are not paid (no salary nor bill) and are not promoted (and co) in the sense of accessing corporate benefits and obligations (week end calls, etc.). So before creating new workflows, what does the service accounts process not support in a robot lifecycle? If anything, isn’t improving the service account workflow easier than reinventing something?

Marc Boorshtein / Rey: Yes. I think that if you fix your service account management it would likely cover robots. Most orgs have paper-based service account management (if that).

James Dodds / Yoda: They are both nonhuman accounts, young padawan. Just different classes with different paths.

Quick shot of Mike’s / Kylo’s mask being repaired (presumably from the damage previously caused by Marc / Rey with the up-close-and-personal Jackie-Chan-style lightsaber leap.

Mike Kiser / Kylo Ren: (Somewhat less angrily) What does it look like if the use case spans applications?  I’ve seen orgs with a bot that accesses lots of different apps all in one workflow. Isn’t using service account governance segmenting that artificially?

Marc Boorshtein / Rey: Only if you assume that service accounts are scoped to a specific application.

Instant shift to a red filter. Mike / Kylo is carving a path through opponents with his patent-pending lightsaber. There appear to be storm troopers in the background, but the entire focus should be on Mike / Kylo and the hyper-intense crimson saturation which has now blown out our visual cortex.

Mike Kiser / Kylo Ren: (Violently angry, throwing whoever or whatever happens to be nearby) Per Matt, he was stating that they were. Does that mean that the service account is in a central repo? Has to be somewhere, I suppose.

Marc Boorshtein / Rey: I don’t see why they need to be. The only difference between a service account and a user account at a technical level is bits-and-bytes. If AD is your central repository you can store a service account there. If your app doesn’t use a central repo then you have similar issues as user accounts from a data/technical perspective

James Dodds / Yoda: If central repository was non-human account “owner aware,” what a blessing when the death star takes away owner…

Marc Boorshtein / Rey: if you break it down into three layers:

1. Governance

2. Data

3. Integration

#3 doesn’t really change between a service account and a user (maybe a few specific use cases like MFA) and is very application specific.

Rapid horizontal wipe to Matt (Finn) and Matt (Poe) in the middle of a vicious fight onboard a . . . whatever that thing is. He (they?) are definitely being chased by storm troopers on speeder bikes, though. The chase is frenetic, with rapid West-Wing-style dialogue and quick cuts back to Marc / Rey (not present in the battle, but is in a remote location with a great high-speed connection for the impromptu discussion.)

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Finn) You can either scope them to the application owners that the bots are calling, or the business unit owners/managers for the department they are fulfilling the actions for. I’ve seen service accounts tied to either model. The latter seems to work better because it gives them incentives to actually care when the passwords need to the rotated 

Marc Boorshtein / Rey: #2 you need some data/metadata about the account to identify it as a service account and link it to an owner. #1 is where the fun really happens with service accounts

Mike Kiser / Kylo Ren: (Still angry, but out of breath, so is forced to calm down a bit) Agreed on tying to dept. Do service accounts have a lifecycle? Do they get spun up and spun down?

Marc Boorshtein / Rey: In theory, yes. They have all the same compliance issues any other account does.

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Poe) Yes, and their access must be governed and reviewed too.

Jeff Lombardo / Luke Skywalker: +1 there. And in any case it is no different for a service account than for robot account.

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Finn) Heck, most robots/services have 2 identities in the system because they can’t afford the downtime to rotate the passwords in a coordinated attack so they’re given a “new” or second account with the new password when it’s time to rotate. (Did I mention how much I hate enterprise software?

Jeff Lombardo / Luke Skywalker: Credential vaulting for scripts (A2A) can now support many schemes so it won’t be a problem to adjust that to robot callers.

Marc Boorshtein / Rey: Assuming your app knows how to use it.

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Poe) Agreed, assuming the software was smart enough to use the vault

Marc Boorshtein / Rey: And there are no standards there. Closest thing you can say is something like secrets in K8S.

Jeff Lombardo / Luke Skywalker: Standards are up to us, but I agree the legacy market has to be dealt with. I was focusing more on the scripting market.

Marc Boorshtein / Rey: Disagree, standards are up to the folks using it (at least from a de facto standpoint).

Mike Kiser / Kylo Ren: (Angrily demanding answers) Can service accounts use PAM?

Marc Boorshtein / Rey: Why not?

Jeff Lombardo / Luke Skywalker: Are we only philosophers in IDPro? I thought we were also the ones using it.

Marc Boorshtein / Rey: If an identity exists in a store, but no application can use it, does it exist?

Jeff Lombardo / Luke Skywalker: Marc, I would say: define “cannot use.” it is still a dormant/orphan account at least. It was at least tied to a purpose in the past so it is never stripped of its Identity. But we diverge from the standards of vaulting.

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As BB-8 and Unnamed Bot) I’d love to see the RPA market give users a way to “delegate” permissions from users to the RPA platform and have them store the tokens and use them on behalf of the user #UMA then when we kill the user, we also kill their OBO tokens.

Marc Boorshtein / Rey: RPA?

Mike Kiser / Kylo Ren: (Didactically angry) The narrator already told you! Robotic Process Automation!

Jeff Lombardo / Luke Skywalker: That’s the new term.  Old made new.

Mike Kiser / Kylo Ren: (Resigned, but still angry) I think a ton of people are using Blue Prism, etc. and so want to govern them from a bot perspective rather than a service account model. 

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: (As Poe and Finn at the same time, with the same intonation and rhythm) Aren’t they all Digital Transformation = Web 3.0 because we already used Web 2.0 and it doesn’t sound as cool? We’re heading right back to mainframes that just don’t live on site anymore.

Fade to a two-pronged sequence. First is a medal (similar to the one from the end of “A New Hope”) held by immaculately manicured hands. Then fade into a close up of Marc/Rey embracing Leia. Next two lines are voice-overs.

Mike Kiser / Kylo Ren: (Oddly upbeat) I feel like service accounts is a good area to account for, but I think that we’ll have to account for bots as an identity type rather quickly. The assumption may be scripting at this point, but I think that long term there will be agency involved. At that point, I think we’ve moved beyond a simple account.

Marc Boorshtein / Rey: it’s all just data.

 James Dodds / Yoda: The bots are all over the enterprise. If not accounted for by now, already behind we are! In a dark place we find ourselves, and a little more knowledge lights our way.

Jump cut (again) to Jonathan / Lando sitting beside Chewbacca in the Millennium Falcon. They jump to light speed as Lando laughs, handsomely. Note: this is very similar to Lando’s other scene, but this time they come from the opposite direction. Wherever they’ve gone, they’re clearly returning joyfully.

Jonathan Sander / Lando Calrissian: (Chuckling to himself) Some of this strikes me as a difference in business model needs. bots that span apps are likely associated with business roles (people or other) that would need to do that for business reasons. In a mesh org where humans cross those lines it only makes sense that bots & service accounts may do as well.

George Dobbs / Narrator: If HR dept. owns records for employee-humans, and Procurement dept. owns records for contractor-humans, who owns records for so-called robots? 

James Dodds / Yoda: I do. I mean I AM, am I?

Back to Marc/Rey, still staring across a tempestuous sea, still with the remains of what looks to be a death star on the horizon, but now with all of the key players. (Except for Mike/Kylo, because that would either be socially awkward or a massive spoiler. Or both.)

George Dobbs / Narrator: For a more amusing question. What is the collective plural for robots? A herd, pack, gaggle, murder, parliament?

Matt Topper / Finn / Poe Dameron / BB-8/ Unnamed Bot: I like Swarm, makes people feel like the drones are coming.

Jeff Lombardo / Luke Skywalker: (Summing up all that he said before to drive home the point, with music building to a crescendo) Bots will always be with you. No one’s ever really gone.

Fade slowly to back, with a haunting, digitized laugh echoing throughout the landscape.

Fade to black. White text fades in (embedded in the IDPro logo, if we had one):

THE RISE OF BOTS

. . .then fades rapidly back to black.

The post The Rise of Bots IDPro Episode IX appeared first on IDPro.