That was the EIC16 that was

Each year, the German security consultancy firm KuppingerCole in Munich is organizing a multi-day conference on the theme of identity and access management.

The KC conference was well organized. Nice location for both sessions and the inevitable vendor marketplace. Lovely brochures, event app, fine catering and a lot of famous people. We'll get back to that later. KC is a large company, has many expert analysts and these are actively present. They moderate panels, are chairing different tracks and give presentations.

The conference lasts three days, long days ... the first keynote generally starts at half past eight and the day closing somewhere between 19 and 20. But that's not all, there are also pre- and post-conference workshops. I decided to join a preconf day this year, namely the workshop on the theme blockchain. I cannot give a full overview of the conference, but I will point to a few highlights.

The hype of this moment is Blockchain. The pre-conference workshop lasted a whole day and treated the backgrounds and ideas around Blockchain and also bitcoin. Also on the third day there was extensive attention given to blockchain in one of the four parallel tracks. Briefly: Blockchain is a promising technology (immutable storage of transactions, transparent, fast and cheap), but so far it’s little used (not really an anonymous platform, ‘bitcoin image’ is not very positive). But biggest problem is the issue of trust. Can you trust the blockchain, do you trust the longevity and continuity? But the advice is: go play with it, within a year or three there are business cases and apps to make use of blockchain technology.

Second hype: CIAM, customer Identity & Access Management. And yet, actually not quite a hype, we have already know,  implement and use it. More importantly is the underlying mechanism, namely federation.

More or less the same applies to IoT and Big Data. These developments also look at federated solutions to preserve both the business benefits and guarantees regarding privacy.

Federation was not only reflected in many presentations. There was a separate track in which the OpenID Foundation presented the many developments. Of course there was OpenID Connect (yes, we really should implement this as often and as broad as possible) and OIX (OpenId Exchange, it so looks like the implementation of what I wished for in my old blogs - http://id-use.blogspot.com/2008/06/trust-model-for-identity-providers.html ), but also a number of working groups on the themes of health (the OpenID Heart working group led by Eve Maler of Forgerock) and the Financial Services API WG.

But not everything topic at EIC16 was about IAM technology, unquestionable the most impressive presentation was by Mia Harbitz of the World Bank. She described identity management in a world where a birth certificate is already a challenge. Children with a birth certificate get a vaccination three times as often as children without a birth certificate. She had more shocking numbers of people without a formal identity, without access to life saving services because of it.

Providing an identity to refugees is also a hot topic (especially in Germany, with 800,000 refugees in the past year). This was discussed in a separate track with an interesting panel discussion. It soon turned out that we give refugees an identity because we want to avoid them actually abusing the services paid by us. Not because we want to offer our refugees just enough identity to survive. Sad really ...

An interesting development was an initiative by Ian Glazer (Salesforce). He and Kantara (for example known for User Managed Access – we should make this a default way of customer access control) took the initiative to investigate whether the Identity professionals can unite. The "Keepers of Identity" are increasingly more import, cooperation is essential. More info: https://kantarainitiative.org/digital_identity_professional/

And for those of us who are in despair… there are still use cases for on premise use of Active Directory. Kim Cameron (Microsoft) sees a shift to Azure AD, but an on premise AD will still remain for the coming years.

These were intense days. I finally met with many digital friends. And I advise you to look up the hashtag #eic16 on twitter. Lots of nice tweets, many photos and video’s and links to interesting articles.

And do yourself a pleasure and visit the blog of my good friend Alessandro Festa...

European Identity & Cloud Conference 2016

This year  I managed to plan my trip to the European Identity & Cloud Conference 2016 in Munich, again hosted by KuppingerCole. I have visited this event before (had a talk about some ABAC developments), This time I'm just a conference consumer. But I will try to post some news now and then. For real-time notifications, follow my Twitter account @meneer, but you get a lot more information by following the conference hashtag, that should be #EIC16 :)

Hot topics: #blockchain, #CIAM (Consumer Identity and Access Management), Privileged Account Management (#PAM), #Cloud and #Governance

You can find out about the program here.

An unexpected ABAC challenge

Currently three of my assignments have an interesting similarity: attribute based access control, all at the same time. And for all customers the choice for ABAC is related to rebuilding the internal application landscape. These customers are not implementing ABAC to facilitate federation of external identities, they're implementing ABAC for internal users of internal systems. There are multiple drivers for this change. There is, of course, the desire to publish internal services to external parties, some day. But there's also the concept of service orientation and the use of service buses and web services. But the concept of separation of identity provisioning and service provisioning is gaining ground as well. Explaining the pro's and con's of ABAC for both business and ICT is no longer a mission impossible.

But at the same time I experienced that there is an interesting and unexpected blocking factor: the application developer. It seems that where both the business user and ICT operator like the added value of federation and ABAC, the application developer has some trouble to get a grasp of the new paradigm:
There is no login page for an app anymore, no users table, no account name or password to manage. How do you implement access control without  a user database and an authorization table with roles? And if users don't log on to your app, how do you know who they are?

An unexpected problem for sure. We need to educate developers as well, to ease the paradigm shift.

How to manage non personal (system) accounts

Customer often ask me for best practices regarding management of non-personal or highly privileged accounts in the process of implementing an Identity and Access Management (IAM) solution. This is an interesting question, because in an IAM project, we try to manage all kinds of accounts, but this type of account is different from accounts that are owned by end users. This type of accounts can’t directly be related to a uniquely identifiable person, nor are they the result of the 'joiner – mover - leaver' HR processes in an organization. So, how do you manage the existence of such an account?

Types of non personal accounts

There are Non Personal Accounts (NPA’s) and Non-personal System Accounts: (NPSA’s). We can identify:

-       Admin or root account

The admin or root account of Windows and Linux or Unix servers is highly privileged system account on the respective platforms.

o   It is authorized at the highest level

o   It has access to every file and process running on a platform.

o   The ‘root’ or 'Admin' has the permissions to change the behavior of their component;

o   Commands can be run from it as well as react to responses of the system.

o   Operational use of the account needs to be monitored continuously.

-       Superuser account
It's a business information system or application account, that looks a lot like ‘root’. It is there when the system is installed, it’s a system account. The Superuser has permission to modify, making it a risk critical account in an information system. Like Sap* in a Sap environment.

-       Service account

Accounts for middleware processes like DBMS’s, ESB’s or other ICT components that run on top of the Windows or Linux operating systems. A special form of a non-personal account is an application account in a DBMS to give database access to an application.

-       Batch user account

An account used by a batch job process, it is most commonly used for scheduled batch jobs, like nightly file transfers.

NPA characteristics

NPSA’s have a few characteristics in common. They are non-personal and they are not directly connected to a person. Login with the account doesn’t leave an audit trace showing which person is actually using it. And, of course, NPSA's are very powerful and so use of them should be tightly controlled.

Service and batch accounts also have a specific similarity: one typically doesn't login with such an account, these accounts are not used interactively. In most cases such an account is only used as a placeholder with some permissions to perform specific tasks, like running a webserver with the limited capability to process https-requests and write log files.

Modern IAM solutions can be implemented to facilitate provisioning of personal accounts for specific user functionality. Since non-personal accounts are not an attribute of an identity, there is not a sole user that can be connected to an NPA, so an IAM solution is not suitable to manage them.

If not an IAM problem, then what?

These accounts belong to the component that they manage. The Windows operating system comes with the Administrator account, Linux comes with root. You cannot install Linux without a root account. You may not by default be able to login with it (as on Ubuntu), but the account is there. So by installing an OS, you automatically get the 'God'‑account. There is no choice, it is the result of the change process that leads to the implementation of the OS. Such an NPSA should only be used in a controlled manner from specific processes, like an incident management process (admin may be needed to assist in a catastrophe), or the change management process (the admin permissions may be required to perform an infrastructural change).

The same is true for service accounts: when installing a middleware component, like a database management system, the account is created to enable the service, hence the name service account. Again, you have no choice. You might install the service using a 'root' – type account, but that will result in a security violation, Thou shalt not run any service as root!

And again, for batch account the same is true again: a batch process is created as the result of a change request. The batch tasks are created to support an information system, or a business process. The batch job is created to make it possible to schedule the automatic execution of the tasks. A batch account is created to make it possible to use resources on the system.

This leads to the following conclusion:

Non-personal accounts have to be managed in the change management process.

This has the following implications:

• The account has to be registered in the configuration management database, it is an attribute of the component that it belongs to. Admin belongs to the Active Directory. Root belongs to a linux server. The account named 'Oracle' probably belongs to an Oracle dbms instance: the dbms is a managed component and the account name is Oracle.
• The account has an owner, who is accountable for the use of the account. Admin and root belong to the manager of the ICT department. The SAP account is owned by the system owner of the SAP system
• The interactive accounts should only be used for infrastructural changes or calamities.
• The non-personal system accounts should never be used interactively for operational tasks.
• The passwords of these accounts must remain secret. They should be secured by means of an envelope procedure, a password vault, or by using a Privileged Account Management system (PAM, like CyberArk, Hitachi PAM, Thycotic or CA PAM to name just a few). Any use has to be related to a service management ticket (an incident or a change). 

So, there you have it. Non-personal accounts must not be managed in an IAM solution, they have to be managed by the Change Management processes in an organization. Either they are owned by ICT or by the system owner who owns the information system that the account is used for. You should not manage privileged accounts in an IAM solution. And if you have to execute tasks with one of these accounts: use a Privileged Account Management system to secure it.

No business case for Identity Providers (part 3)

Would I like to be an identity provider?
Well, of course. I would make sure that my identities were very reliable and reusable. My identities must be trusted in order to make them reusable by different service providers, the government, banks and other websites. This, of course, requires the use of open standards and an auditable governance and trust framework. To achieve this, I need a business model, because someone has to pay for all this. In my opinion there are several models:

• The citizen/customer pays for his digital identity
• The citizen/customer gets a digital identity for free, no costs
• We license a trust framework

$Identity

Anyone requiring a digital identity by a trustworhy Identity Provider needs to pay for the use of the digital identity. The question is if I, as a consumer, would be willing to pay for a digital identity. If I can't use the identity, I don't want to pay for it: 'What's in it for me?'. This model requires a convincing story: as a consumer I need the assurance of the reuse potential.

If I were an identity provider, would you pay for my digital identity if I could guarantee reuse? If so, how much? That's difficult to calculate. There are many costs attached to running a trustworthy identity management system. Most of theses costs are fixed costs. The more identities I can sell, the lower the management and security costs per identity and thus the lower the price of a digital identity. How about $20 for every identity? And with a periodic renewal every 2 years? Because identities erode.

Zero$ identities

There are different variants of this model.

1) Like I mentioned in an earlier post, the Dutch DigiD is an example of a trustworthy free identity. The identity is free, the costs of the identity are made up for by the identity provider. Because of the use of DigiD, Dutch citizens can perform a lot of G-C transactions online, data entry is moved from the civil service to the citizen. The disadvantage of this model is that the reuse potential is low. The identity can only be used at a fw service provider within the trust framework, like local government and a limited number of legally appointed third parties.

2) Another instance of this model is a company that pays for the costs of identity management and provisioning for it's own customers. Just like the mentioned Digid case, but with a larger reuse objective. All parties in the trust framework abide by the rules of the trust framework and guarantee the conformance to the rules. This means that there should be auditable quality and trust criteria, resulting in some kind of a seal of approval... It looks a lot like the OpenID+ model I wrote about in a previous post.

An identity that can be used often, has a higher value that an identity without reuse potential, hence an identity provider with high reuse value identities will have a better reputation and may be willing to invest in this identity provisioning service. What will this cost? The trust framework will be expensive, so the costs of such an identity will be higher than the costs of the first model, let's say $50 per identity. Investments with a positive Return on Investment, even more if the service will result in frequent customer contact as well, for instance because of periodic renewal of the identity.

Commercial providers of free identities like Facebook, Twitter and LinkedIn, implement this model in some way. The reuse potential of this model is moderate to low, because of the lack of a Trust Framework. Only service providers within the trust framework of the identity provider (think of Blogspot, that enables you to use your Gmail account to logon) offer the reuse potential. Other SP's, who don't require trust, but who just rely on the identification and authentication of a customer, may allow the use of a free account.

What is the business case for identity provisioning for these commercial IdP's? They offer a free digital ID, but who is paying for it? Because when using it, by logging in using open protocols like Oauth, there is no transaction fee for authentication. This is an interesting question. These IdP's seem to gain a lot of money by managing your digital ID in a different way. Managing and securing identities is costly, but their business model has an enormous ROI because of the services they offer by analysing the value of your identity, your profile. Your behavior is valuable…

Is such an identity a good match for all purposes? Obviously not. there is no trust in your digital ID, because, no matter what 'real name' policy, the IdP doesn't really know you, it only knows your profile. And the provider knows every service provider you use, based on your logon.

You could upgrade the value of an untrusted digital ID, by using a third party verification schema. For instance upgrade your twitter account by having it validated by another trust framwork. This of course creates a larger reuse potential (in the other trust framework) with your simple logon feature. But of course, someone will have to pay for the added trust by verification in a third party trust framework. There's no free lunch...

3) The third instance of this model is that an identity provider gives out free identities, but makes service providers, who trust the identity, pay the fee. That could be based on a per per use fee, or in a subscription kind of fee. This creates a high reuse potential, within this trust framework. In this way the service provider doesn't have to pay all costs for identity provisioning, thereby saving a lot of money and limiting compliance risks – if you don't manage identity data, you can't lose them… How much should this cost? Hard to say, but I think that $0.10 per reliable authentication could well be feasible. Or a subscription fee of, let's say, $10 per customer per year?

For IdP's there is a real incentive to create as much reuse potential as possible. The more often an identity is used, the higher the profit. But reuse potential is a result of reliability and reputation, Identity Provisioning is an expensive business model. And if a digital identity is not used often enough, this will result in a financial loss.

Last model...

Let's just create a trust framework and have anyone use it. Both identity providers and service providers pay a license fee and can start using it. The trust framework guarantees reuse and every party can decide their own business model (I wrote about this long ago...). But the trust framework has to be developed, managed and monitored, according to open standards and governed by legal standards. But someone has to pay for this model too. And there is an example, OIXby the Open Identity Foundation.

Lingering business case problems...

There are some other problems for identity providers and service providers. From the business case the main driver for profit is the reuse potential of digital identities. Only if there is any reuse capability, operating an IdP can be affordable. When not, there is no business case. If an identity cannot be reused, it may well be too expensive for the customer, the IdP or the SP.

But there is a strange oxymoron… The better the reuse potential, the less I am inclined to use other identities, the one with the best reuse potential will be my preferred ID. This means that I don't need another IDP. And same is true for other consumers as well. This means that there is limited room for other IDP's. (I know, you may want to use more than one identity, but that's out of scope for this post :) )

Is there a business case for IdP's?

No trust framework, no reuse. No reuse no business case. No business case no digital identities. No digital identities, no trust framework. No trust framework, no reuse, no business case.

I may want to be an Identity Provider, but I don't believe that there is a business case, unless you manage to be  the same league as facebook and friends...



(based on my Dutch language post https://www.cqure.nl/kennisplatform/digidem-4-het-opbrengstenmodel)