Found: Identity Provider Business Case, or not?

I had the pleasure to have been part of the Identity community in the “early days”. Right before OpenID came into existence and most people thought of Microsoft Passport as innovative. One very hot topic was the idea of an “Identity Provider”. An Identity Provider is a party on the Internet who would be happy to serve any claims about me to a any relying party, obviously with the user’s consent and control. Anyone remember the expression “user centric identity”?

There were some unsolved issues:

  • How would an Identity Provider make money to pay for the operational costs?
  • How would relying parties know which Identity Provider to trust?

Especially the second issue was hard. Some relying parties just want to be able to recognize recurring visitors and are happy with a couple of standard attributes. For them, identity has low value. Well known examples are the myriad of forum sites.

Other relying parties however want more, they want identities with verified attributes, an identity they can trust. For them, identities have value and untrusted identities come with a business risk. An extreme example would be a financial institution who would, for these reasons, typically never outsources the Identity Provider role.

A couple of days I came across an interesting article about Facebook offering their commenting system to other sites, including authentication through Facebook. What caught my eye was an argument showing that Facebook serves as an almost perfect Identity Provider in some sense:

This offers publishers a number of benefits. They get more links to their site from inside the net’s most popular website. A lot of people are “registered” to comment on their sites. And, they have a system designed to discourage vitriol because it’s easy for the site owner to ban a user and tough for a user to create a new identity.

Especially that last part is interesting: relying parties can put some trust in the provided identities simply because … people invest time and effort in their Facebook identity and generally would not throw this away just to post rubbish on some forum. In other words, relying parties will like Facebook identities. They trust one Identity Provider, Facebook, and they get hundreds of millions of fairly trustful Identities.

But what is in it for Facebook? A lot!

For Facebook, the benefit is also clear. Users now have even more incentive to be constantly logged into Facebook (those who are already logged into Facebook don’t have to do anything to comment on a website using its system). Additionally, even more of Facebook’s users’ net activities flow through its site, since by default comments — and replies to them — post to a Facebook user’s wall. That deepens users’ ties to Facebook, adds more content to Facebook, and gives people more reason to check their Facebook newsfeed for the increased information flow.

By allowing relying parties to use Facebook identities to realize a comment system on their site, Facebook actually generates value for themselves. A win-win it seems.

Facebook, with their Facebook Connect, wants to be the primary Identity Provider on the Internet:

It also builds on what’s becoming Facebook’s most important function: being the identity provider and validator for the wider net. The system opens the door for what’s likely inevitable: having news sites rely on Facebook to identify its users and eventually to serve ads to its readers based on their individual Facebook pages.

Both issues are gone: the Identity Provider (Facebook in this case) can have a very viable business model and the relying party has an Identity Provider they can trust, one that brings hundreds of millions of identities.

So, all well now in the world of Identity? I don’t think so. The relationship between Facebook and relying parties is not a balanced one. Relying parties are clearly at the mercy of Facebook:

… just as Facebook jealously holds onto the e-mail addresses of the people you are connected to on Facebook so you can’t re-establish your network on some other site.

Promising as it may seem, this type of unbalanced relationship should not satisfy us. So, for those still active in the field of Internet Identity, what do you think about this?

Automating Business Services in ArchiMate

02/10/2010: after posting this, there were some insightful comments made. I encourage you to read them as well.

I am generally very enthousiastic about ArchiMate. What is not to like? It produces elegant models that are easily understood by a broad family of stakeholders and the viewpoint categorization is refreshing and very useful, especially compared to for instance TOGAF 9. It’s not all sunshine however, there are for instance a couple of points in ArchiMate where I tend to differ in opinion with some fellow architects.

One of those points are the assignment relations between the application layer and the business layer as shown, using bold red, in the following subset of the ArchiMate 1.0 metamodel.

Before I go any further I have to state this disclaimer: I will explain my point of view given my current understanding of and experience with ArchiMate. If you have any remarks, negative of positive, on the reasoning presented in this post, I would appreciate if you would post a comment or contact me directly!

Metamodel (click to enlarge)

According to the specification (see Chapter 7 “Cross-Layer Dependencies”) these relationships have the following meaning:

Assignment relationships, between application component and the different types of business behavior elements, and between application interface and business service, to indicate that, for example, business processes or business services are completely automated.

In short, in case of complete automation, you assign active structure from the application layer to the business behaviour instead of the, usual, active structure of the business layer (actor and role). With this active structure from the application layer, an application component, comes the external structure, an application interface. The application interface will be the interface through which clients use the business service.

Let’s develop a small and simple example where we use these relations, explore their meaning and identify potential pitfalls.

A company offers a customer support service to their customers, this service, “Customer Support Service”, is realized by a business process “Customer Support Process”. This process is executed by the customer support department who offers a phone interface for customers. The process itself is fairly simple, first the support request is analysed, then a knowledge base is searched to find possible answers, the possible answers are combined into a support answer for the customer.

As you can read in the process description, the actors in the customer support department use a Knowledge Base application. They access it through a web interface. This application offers a service where you can browse and search common problems and their resolution. The customer is not directly exposed to this Knowledge Base application. The model belows shows these elements and their relationships.

Example #1 (click to enlarge)

We haven’t yet used the assignment relations between the active structure of the application layer and the behaviour of the business layer.One way to introduce them is to simply state that instead of offering this service using the customer support department, it is completely automated with direct access to the Knowledge Base application. The Knowledge Base application is capable of performing a simplified version of the Customer Support Process and the customer directly accesses the web interface. The business process has to be simplified before it can be completely automated. Our Knowledge Base application is not, as most applications aren’t, capable of intelligent analysis of the support request or possible resolutions.

Example #2 (click to enlarge)

The above simplified situation, with only a completely automated realization of the business service, is not very common. In most cases the customer can use both interfaces. The Phone interface is offered for customers who are unable or unwilling to use the web interface or whose questions are just too complicated and require a customer support representative. The web interface is offered in case the customer has access to the Internet and is able and willing to use the direct web interface. At first sight we can simply model this as seen below.

Example #3 (click to enlarge)

But is this correct? We have an application component whose internal behaviour is represented by a business process, it completely automates the business process, But this process behaviour itself uses an application service that is realized by … this very same application component! That sounds pretty much like an endless loop. I don’t think it is impossible as such, depending on the level abstraction level of the process definition or the level of composition of the application component, you could defend the above model. But honestly, I feel it would barely represent reality.

It is clear that we want to avoid having a business process that uses an application service that is implemented by an application that itself completely automates that business process. Yet, the situation with two interfaces to a knowledge base, one offering access through a customer support representative and one offering direct access to the application, is very common. Both interfaces support the same buFsiness service, they both fulfill the same customer need. We can’t use a single definition of internal behaviour though, so let’s update our example and define an extra business process. This new process is a simplified version of the original process that only allows simple questions and is therefore easily automatable. This new situation is shown in the diagram below.

Example #4 (click to enlarge)

The above example has been kept as simple as possible. In practice it would be unlikely that the original web interface of the knowledge base application would be considered usuable by customers. In most situations you will find a new application that offers a more suitable interface for end users, this application will use the original knowledge base application through an application-to-application interface (this interface is not shown on the model).

Example #5 (click to enlarge)

These simple examples show my current understanding of these particular relations in ArchiMate. If my understanding would be incomplete or even flawed, I hope to find constructive comments to enlighten me.

My pin code is … ****

Yes, you read that right, I gave you my pin code, it’s … ****. Of course, unless you lack a brain, you know that **** is not even a valid pin code. It’s what you see on screen when you enter your code at any ATM. No need to protect that … or is there?

One bank in Belgium goes to great lengths to protect you from devious people trying to read that “****” while you enter your code. They have a special film on the display that makes it impossible to read the display unless you are standing perfectly in front of it. So, nobody can read that “****”, only you can. They even have a sticker on the machine telling you how they do their best to protect you.

They do not protect you in any way from someone looking at what you type on the key pad though. In fact, from the looks of it, they do their very best to make it as easy as possible for strangers to see what you are typing on the key pad.

I know many of their ATM locations are surrounded by excellent spots from which you can undisturbed see any pin code being entered on they key pad. Even when the ATM is indoors, it is conveniently located near a large bright window. A large bright window lacking any protecting measures for that matter. Someone living in the house opposite the street can easily farm many pin codes a day.

It’s good to see how smart people are doing their very best to protect me from fraud and theft. Thank you.

Some still don’t get it!

This post is about security, so if you are not into that, feel free to skip it.

Today I get a friendly email from the national railroad company of Belgium (NMBS) in which they announced a brand new site to order international train tickets. It also mentioned that instead of using my made up user name I could now use the email address I used while registering to log in.

That sounds great, another site that uses an email address to log in instead of something like “johnsmith342”.

Then they kind of messed up. For my convenience and to make sure I would be able to use their shiny new site to buy lots of international train tickets they included my password. Yes, you read that right, they mailed me my password. Without me asking for it.

They have no clue about processes and procedures for dealing with passwords. They are not helping the world in teaching people how to deal with authentication secrets, social engineer and phishing.

I can only hope the password is not stored clear text. Due to password policies it is often necessary to access the password in clear text, only storing a hash is not working any more. Common databases like Microsoft Active Directory, Novell eDirectory and probably many others use two way encryption to store passwords. They have many secure access layers between a public api and the encryption keys to access to the clear text version of the password.

Honestly, emailing me my own password without my consent doesn’t generate a lot of trust in how they deal with sensitive information. That includes my trust in how they store my password in their systems.

Set UML Free

Yesterday I received an invitation to support an effort to set UML free. You can read all about it on webuml.org. Currently the site is a wall of text (tip for the authors: less is more … and there is nothing wrong with a picture or two ;)) but if you have some spare time I encourage you to read through it.

The basic idea is to provide for online collaboration while modeling with UML. You can’t really do that today. The best you can achieve is to email some images of UML diagrams around or hope for the best with XMI. webUML aims to create an online collaboration environment using modern web technologies. They already have a powerful UML drawing canvas ready, including an integration with MediaWiki.

I see a future for this effort, if of course they can achieve minimal functionality (which I think they almost have if not already) and critical mass (that’s why they are promoting it right now).

There is however one thing that caught my attention: a promise for a plugin for Enterprise Architect from Sparx Systems so it can access a webUML central repository. If that plugin ever becomes reality and that central repository is HTTP accessible (sounds like a good REST challenge) they will have made me a happy architect. Integration with business tools and the business environment will be, in my humble opinion, key for mass adoption.

I would be really happy if there would be support for BPMN and creation of custom viewpoints and models (meta modeling).

But one should not ask too much and be happy with what we get. So please support the webUML effort, help if you can and spread the word.

While reading up on webUML I also came across this little gem: The Model Factory. A wiki on design patterns from the point of view of modelers. Implemented of course with webUML technology. Bookmark added.

Set UML Free!

One Trick Ponies

Recently I came across an excellent article on One Trick Ponies in the world of architecture. One trick ponies who know only one type of solution and desperately try to make that one the only possible solution.

This part of the article made me smile, especially since it perfectly describes my sentiment after a situation I experienced not so long ago:

Now while I look down on these people, because lets be blunt they are lying in an attempt to secure a project that they aren’t qualified for based on the hope that they can somehow pull it off. (A dazzling example of managing risk … upwards!) Why people do this I’ll never know it ALWAYS ends in tears. But I guess it keeps the cash flow going for a while.

My personal experience involved an external expert who insisted that, for a simple Java project, storing data in a database on an IBM System i would be impossible, it would cost enormous amounts of money to access and integrate this “legacy mainframe” from the Java world. I challenged the expert and asked him what kind of database was used on an IBM System i. An awkward moment of silence followed. The IBM System i uses DB2, a well known and proven database technology, it is extremely easy to access it from a Java program. In fact, developers won’t even notice the difference between the System i DB2 instance or a Windows instance.

This expert tried to guide a company towards a more expensive solution simply because he was more familiar with it. The IBM System i DB2 solution was unfit because he could not be part of it.

Of course, no architect can know every piece of technology or platform. You are bound to encounter something you are unfamiliar with. But if you do, be a professional architect and investigate, read up on the basics and find knowledgeable people inside the company who can help you fill in the details.

From The Internet – 22/11 2009

Various resources on the Internet you might find useful. At least recommended reading for a spare moment.

ArchiMate and TOGAF. Four excellent papers comparing ArchiMate and TOGAF:

Some attempts at defining the concept of “business function:

Miscellaneous

Cloud IT as an Architectural Style

Martin Kuppinger from Kuppinger Cole, known from the excellent European Identity Conference, wrote a very interesting article on Cloud Computing: “It’s not about the cloud – it’s about Cloud IT“.

But the more you dive into the topic of cloud computing it becomes obvious that this cloudy thing of “cloud” (usually associated with the Internet and things which are provided there) isn’t the key thing. The key to success is that companies understand the value of Cloud IT.

What does this mean? Cloud IT stands for consequently using cloud principles in IT – and in every part of IT, not only for consuming some external services. That includes

  • well defined services (SLAs!!!)
  • a consistent service management across all services, regardless of where they are running (and, based on that, consistent approaches to cloud governance)
  • applications which are agnostic of where they are run or which hardware resources are available – there have to be parameters which might limit the ability to run applications everywhere and the application has to accept the currently available hardware resources but as well should understand that these resources can change dynamically

Defining everything in IT as services in a consistent manner is a fundamental change and the foundation for a flexible use of cloud services. Once you have made that move you can decide (based on parameters of a service) which service provider (internal or external) you will use. Thus, the first step is making your IT “cloud-ready”, e.g. moving towards a Cloud IT. Without that, using cloud services will always be sort of tactical and not strategic.

On the last day of the 2009 edition of the European Identity Conference I participated in a workshop on Cloud computing and Identity with Martin. In the workshop I told Martin that for me, an architect, the most interesting aspect of Cloud Computing is not the ability to house your application logic externally but a renewed and global attention for various architectural patterns.

The underlying current for most of these patterns is a high degree of abstraction and transparency combined with simplicity (not the bad kind, the good kind). In other words: keep it simple, abstract away everything that is not part of your application and don’t care about the environment you are running in (for instance network transparency). The advantages of following these principles are becoming more obvious due to Cloud Computing: scalability, continuity, flexibility, reusability …

Those patterns can equally be applied to classical internal IT. Yet, you rarely see this except at the application level. Cloud computing forces you into this thinking, traditional IT however gives you enough escape hatches. Not in the least because vendors keep on selling solutions that stifle innovation. As a simple example you can take the infamous network transparency. Demonstrated over and over again in the last 3 decades to be achievable (see for example the Inferno operating system) yet most commercial solutions still expose the network to you. So many good “inventions” but so little uptake from vendors.

In conclusion: I can only join Martin in his advice: get your IT cloud ready, move to a Cloud IT. Even if you will never ever actually move to the cloud. And more importantly, put pressure on your vendors to force them to innovate!

[edited: corrected some typos and grammar]

We care about you … sort of …

Some companies insist on letting you know that the mail you just received from them, has been properly scanned, dissected and cleansed before it reached your mailbox.

Sometimes it can go wrong however:

Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.1/1517 – Release Date: 24/06/08 20:41

I wonder if I should delete the mail or not. As a juice extra, somewhere else in the mail they refer to their company as “Your IT Reference on the Web !“.