Identity and Access Management (IAM) is core to many enterprise architectures. Centralizing the authentication is mandatory once you have more than a few systems, and IAM providers fill that requirement nicely.
On first thought it might seem blockchain has nothing to do with IAM. But that would not be entirely correct.
There are two aspects of blockchain and related technologies that make sense in an IAM context.
Self-sovereign identity
The first aspect is Self-sovereign identity – this is a very interesting concept that aims to replace traditional identity providers. The goal is to allow each user to fully control their own identity while not relying on a centralized provider. The “identity” is a set of attributes, including name, age, address, a unique identifier, national identifier, identity documents or even biometric data.
There isn’t a unified view on how exactly self-sovereign identity should work on a blockchain infrastructure, but one way would be to store the attributes in an encrypted way and let a smart contract decrypt them when needed. Storing them encrypted is needed for privacy reasons, and storing them at all is needed if someone else is needed to attest that they are valid. Alternatively, only the signature on the hash of the attributes may be stored on the ledge, while the user presents the attributes dynamically from their device.
There are a few issues with that, however:
Issue #1: usability
First, it heavily relies on the user owning and securing their private key. This is often a usability hurdle – there’s a need to understand what a private key is in the first place, the user needs to write down recovery words or risk losing their account as there’s no centralized account recovery. There’s obviously the cloud key storage services which ideally rely on a password-based key to encrypt what’s stored in the cloud. This ultimately means the profile is protected by a mere password, regardless of all the underlying cryptography.
Issue #2: many cases require a central authority
The second issue is the complexity of attesting attributes – in many real-world use-cases you need a centralized authority to certify the attributes. Be it a government, a bank or similar institution. So for practical reasons, we still rely on centralized trust, even though the technology itself is distributed. It does give flexibility to the user, of course, and has support for multiple attesting bodies for different contexts, but where it matters (e.g. banks doing KYC), you always end up with verifying the identity document issued by a government authority.
Issue #3: flexibility for the enterprise
The third issue is the flexibility in terms of the enterprise. Running the blockchain infrastructure in a centralized fashion loses the decentralized benefits, while retaining the complexity of it. On the other hand, relying on the decentralized network means the enterprise has much less control on the governance, and they must absolutely have their own layer ontop of that which can handle authorization. In that sense, a typical IAM is much more suited for the enterprise.
Outside the scope of the enterprise, however, self-sovereign identity remains an interesting frontier which, even if not universally applicable, can be used in certain cases instead of the broken username/password pairs.
IAM and Audit Trail
The second application of blockchain in the context of IAM is the audit trail. As IAM centralizes authentication and authorization, it is a prime candidate to securely track all access. This is often required for compliance reasons and helps the enterprise in prevention (and detection) of fraud. So each time a user logs in or requests certain permissions in certain context, an audit trail entry is logged. Each time a user is enrolled, deactivated or their attributes are modified, an audit trail entry is logged.
But simply having the audit trail stored in some text file or database won’t cut it, as it allows certain privileged users to modify it, delete entries and even to back-date fake entries. Because of that limitation, the forensic usefulness of the audit trail is significantly diminished. Yes, “who logged in where and when” can still be investigated, but if fraud is committed, and especially if privileged users are involved, the audit trail will not be reliable.
Here comes blockchain, or more specifically its underlying components – the hash chain, the merkle tree, the cryptographic timestamp and the digital signature. Combining those elements in what may constitute a private blockchain solves many of the issues of IAM audit trail that exist today. Obviously, each of the audit trail entries can be sent to a public blockchain, but at the scale of a typical enterprise they would be pretty expensive and few businesses want their internal audit trail pushed to a public network (even if duly encrypted).
This is what we at LogSentinel are doing – we accept audit trail entries and form an internal blockchain structure. For additional security, the internal chain is regularly anchored to a public blockchain (e.g. Ethereum) without leaking any corporate details.
We have some IAM-specific features:
- The authentication endpoint allows setting specific predefined authentication actions like LOGIN, LOGOUT or LOGIN_AS among others. This is just for convenience, as any custom event can be defined.
- The
Signed-Login-ChallengeandUser-Public-Keyheaders allow users to sign authentication challenges and these signatures are then stored as part of the audit trail. This not only ensures that the log was not modified, but also increases the level of certainty that it was indeed this user that performed the action and not anyone else, provided there’s a PKI in place.
Obviously, no solution exists in isolation, which is why we support the built-in audit trail of multiple IAM solutions. Our agent, after simple configuration, can collect and securely store all these events for extended period of time in a way that guarantees their integrity and allows independent verification – from auditors, for example.
We support OpenAM (as well as other ForgeRock products), Keycloak, Okta, CAS, Centrify, Ping, RSA SecurID Access, Shibooleth IDP , and many more. Basically anything that logs to a database, text file or syslog is supported.
We believe that blockchain can solve the problems of the enterprise and can improve security, accountability and transparency. And that’s why we view storing the IAM audit trail with our SentinelTrails product an important measure. And it’s one that doesn’t require reorganizing the entire IAM process (as a self-sovereign identity would do).
Bozhidar Bozhanov is a senior software engineer and solution architect with 15 years of experience in the software industry. Bozhidar has been a speaker at numerous conferences and is among the popular bloggers and influencers in the technical field. He’s also a former government advisor on e-government, transparency, and information security.
