BYOI (Bring Your Own Identity) : Practical guide to handle Unicorns

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Buffer 0 Email -- 0 Flares ×

BYOI is a series I’ve decided to create to “talk” about #identitymanagement so it is about #security, #governance, #management and many other aspects of the #IAM realm.

The unicorn is a legendary animal from European folklore that resembles a white horse with a large, pointed, spiraling horn projecting from its forehead, and sometimes a goat’s beard and cloven hooves

wikipedia  on “unicorn”

Thinking outside the box (also thinking out of the box or thinking beyond the box) is to think differently, unconventionally, or from a new perspective. This phrase often refers to novel or creative thinking. The term is thought to derive from management consultants in the 1970s and 1980s challenging their clients to solve the "nine dots" puzzle, whose solution requires some lateral thinking.

wikipedia on “thinking outside the box”

My “home” office is a white wall, deliberately, it’s a white wall with nothing attached not because I’m a fanatic of “minimalist” or any other sort of fashion architecture flow but simply because it help me to focus and look beyond the boundaries where I found myself too often encapsulated.

This is a long post so before to embrace the reading I’m warning you.

The “unicorn” is a mythological animal so, by definition, cannot be “solved” but this is because we, as grown  adults in a dichotomist world, tend to look at things only from our perspective that is a way to look at things in a “ black or white” way.  I am not saying that everybody is like this and most of the “solution architects” or “engineers” our there are able to look at things from so many angles that the common definition of “scale of grey” could not even be applied since is too restrictive.

But, again, when you are too much focused on a single side of the “story” sometimes there’s not enough time to stop and look at the other side and discover that your “unicorn” is, sometimes, just a shiny “white horse” for someone else.

Few days ago my attention was catched by one of the, many (TOO many) great episodes of #engineersunplugged.

For those who don’t know what #engineersunplugged is :

  1. Shame on you! you illiterate go to this link and start to learn!
  2. Double Shame on YOU! I tell you just: Cisco,VMware,EMC, everyone is there and share knowledge in few minutes in front of a white dashboard.
  3. Triple Shame on YOU: you should already follow @CommsNinja consequently you should know everything about #engineersunplugged

Seriously is a one of the best blog/idea I’ve ever see because still do what makes Information Technology a great field to work in: sharing knowledge for free and with a simple language that could be appreciated by the  newbie and the expert.

As said my attention was catch by an specific episode where two friends @CloudofCaroline and @mreferre spoke about “unicorns” and “single pane of glass”. I could embed the video here but I think it’s more appropriate to encourage you to go to see the video directly on #engineersunplugged (click on the link on the left) page and come back here.

So in the episode Caroline and Massimo explained the concept of “single pane of glass” even known as “unicorn”. As perfectly said (as always) by both it should be a “monster” who is able to manage almost everything from a single “point of view” and possibly without making difference of ecosystems whether they’re public,private,hybrid,”whateveritis” clouds or on-premises infrastructures.

The picture below show a better view of the result on the #engineersunplugged dashboard.

#engineersunplugged – Engineers Unplugged (Episode 7): Halloween Edition Featuring Scary Architecture

Meeting the Unicorn

A “unicorn” is something similar to this:


@CloudofCaroline & @mreferre “monster scary architecture”

The unicorn present itself as a complex architecture made by:

A first “layer” that is recognizable (the horse body) :

  • A layer made by different ecosystems like:
    • On-Premises Infrastructures
    • Private Cloud Infrastructures
    • Public Cloud Infrastructures
  • An API stack able to provide “connectors” to (but not only) :
    • Services
    • Applications

A second “layer” (the mythological corn) composed by (and not only):

  • A SOA layer
  • A SLDC layer
  • An Orchestrator Component
  • A Compliance(Certification/Attestation/Re-Certification) model
  • An Automation component (CRUD activities of any kind)

it is quite obvious that put togheter all these components and layers lead to a sort of “monster” that, even if able to manage them must do it not only with a single “horse body” but with multiple “bodies” (aka heterogeneous ecosystems").

I’m not going to solving the unicorn providing any kind of advice on using a software vendor or another. My blog post only purpose is to provide a personal point of view and so, even if I can give the same answer as employer of a HW/SW vendor what I’ll try to do here is to be as possible “vendor-free”.

To handle a Unicorn let it come close to you

So it is a “monster” and as every “monster” we are scary from them, we think we cannot handle them and we take them "at distance”.

I trembled and my heart failed within me, when, on looking up, I saw by the light of the moon the daemon at the casement. A ghastly grin wrinkled his lips as he gazed on me, where I sat fulfilling the task which he had allotted to me. Yes, he had followed me in my travels; he had loitered in forests, hid himself in caves, or taken refuge in wide and desert heaths; and he now came to mark my progress and claim the fulfilment of my promise.

Frankenstein – Mary Shelley

At the beginning of this post I cited the definition of “thinking outside the box”, what  make me shudder of surprise when I saw for the first time the “single pane of glass” episode was not that I saw the “unicorn” the way @mreferre and @CloudofCaroline saw it but that I didn’t see at all a “unicorn” neither a “monster” but a long time friend.

The “monster” it is only a “monster” to the eyes who don’t know it, think at the descriptions of whales made by various explores in history as example.

Below I redraw the unicorn from my point of view:


“Single Pane of glass” reviewed.

Let say for a moment (this not the way to handle the unicorn yet) that we can move the orchestrator in a “position” where can act as  bridge between the API stack and the various ecosystems.

The orchestrator is made by a main component who manage the activity discriminating which  connector or sub-orchestrator engage to complete the request made by the actor. The actor is an identity who have access to a single entity/ecosystems through a role.

The  role define what the  actor can request to the  entity and doing so will trigger the  orchestrator in order to fulfill the request. Unfortunately this is only a way to look at the “unicorn” that obviously do not answer to our questions:

  • How I can handle the “unicorn”?
  • Does exist the “unicorn” and if so where I can find it?

Once the Unicorn is at your disposal let know each other

So you see the Unicorn near you now and you know that somehow if this orchestration process could be setup than you got a chance to handle the “monster”.

The figure below represent a more complete view of the “Unicorn handled”.


Unicorn unveiled diagram

We spoke about a “magic” orchestrator but as we even said was not enough to “handle” the “Unicorn”. So let see again the infrastructure we have:

  • The Orchestrator will take care of the so-called CRUD activities in terms of:
    • Users
    • Apps
    • Infrastructure Layers

This is the “main” Orchestrator who do now have nothing to share with “local” orchestrator based on the Provider/Customers ecosystems infrastructure. Those for the “Unicorn" are just the terminal dot of a uni or bi-directional connector.

  • The Workflow layer who must satisfy:
    • Role assignment/reconciliation fo the actor: in terms of who am I on the various ecosystems and what I can, consequently, do.
    • Policies that must be matched in order to proceed in the request made by the  actor.
    • Rules that are directly or indirectly bound to the   ecosystems connectors and that must be satisfy in order to trigger the “remote”  orchestrators.

The Workflow is far from being a complex schema of views, stored procedures or whatever you call it but simply an aggregator of instructions that dynamically evaluate every single request and decide upon it.

  • The Compliance/Attestation/(Re) Certification component must satisfy:
    • Compliance of the request in terms of: Role of the  actor,  coherence  of the request in the relation  who ask toward which ecosystem, need of the request (in terms of evaluate the real-time metrics who allow a request to be made).
    • Attestation/(Re) Certification in terms of guarantee which  actors may be in charge or express a request, to which ecosystems they have access, to which data, at which level, etc..
    • Allowance  of specific connectors (SSO through Social logins, Access to Data in specific silos,CRUD activities for custom Apps/Ecosystems,etc..).

On the existence of the Unicorn

So now if we look back at the last picture our Unicorn  is not anymore a “monster” but more a well-known “animal”. A long time friend who sometimes has been caught struggle in the IT realm because of it’s too much biz-alike models and that lately has seen to come more and more on the mouth of everyone as the “missing piece” of the IT story.

We draw the picture of the Unicorn and we seen that can “easily” manage the  “single pane of glass” but we still do not know how to call it.

IDasS or IDmasS (here for a definition of the name from Kim Cameron) it’s just a name but explain the architecture in many  ways:

  • It can be offered/received from a on-premises or a cloud infrastructure since it manage both and the starting point is not the focus but instead the capacity to connecting dots (connectors through API stack).
  • It is  heterogeneous by definition because it not manage directly the ecosystems but relay on the “local” orchestrators.
  • It acts as a junction point for the ecosystems since it’s main purpose is to aggregate the request and evaluate them in a way with regards of the : rules,policies,boundaries setup by the customer and the Service Provider.

Should be, in other words, something similar  to this:


Hyper-view of an actor from the “unicorn” perspective.

To conclude the “single pane of glass” is far from be an “Unicorn” and if it is far from being solved is not due the unknown definition of  what is is but simply because sometimes we forget to look at things from different angles and perspectives.

Thanks and Merry Xmas and Happy new year to those who inspired me in this post : @CloudofCaroline, @mreferre and @CommsNinja