One of the wonderful things about writing a blog is that people often reach out to talk about something that interests them or ask to meet up for a chat (if they live in Sydney).
Over the past few months, I've had quite a few discussions with various people in person and have found them to be mutually beneficial. In many cases, I actually got more out of it than the person who wanted to meet up in the first place.
I do have a pet peeve however. If you randomly (by "random", I mean if I've never talked to you before either in person or via some sort of online medium) invite me to "connect" with you (e.g. on LinkedIn), at least change the standard message and tell me why you are reaching out.
So, I'm apologising to those of you out there who have sent me invitations on whatever social/business networking thingy you chose and have yet to receive any acceptance on my part. I've just explained why your invite is sitting in limbo.
Back to the actual point of this post: if you reach out to me (in a non-random manner), I usually respond. So please feel free to do so. If you are based in Sydney (or happen to be passing through) and want to meet up for a chat, go right ahead (use my contact form, but please introduce yourself).
If you want to talk shop (Identity, Access, Security), the coffee is on me :-)
Wednesday, October 13, 2010
Wednesday, October 06, 2010
Oracle finally acquires Passlogix
The big news in the Identity & Access Management (IAM) world today is Oracle's acquisition of Passlogix. In fact, I made the observation 2.5 years ago (when talking about IBM's acquisition of Encentuate) that the most logical suitor for Passlogix was indeed Oracle.
It was only a matter of time, but I'm surprised it's taken Oracle this long to officially add enterprise single sign-on (ESSO) to their suite. I use the word "officially" because Oracle's long-standing OEM agreement with Passlogix means customers are unlikely to see much change in the short term. It simply means Oracle will officially own the technology powering their ESSO product instead of having to "repaint" it red & white. You might also see quicker turnaround times in getting your queries answered and your support calls resolved, so I suppose that's a plus.
Congratulations to all the Passlogix gals and guys.
It was only a matter of time, but I'm surprised it's taken Oracle this long to officially add enterprise single sign-on (ESSO) to their suite. I use the word "officially" because Oracle's long-standing OEM agreement with Passlogix means customers are unlikely to see much change in the short term. It simply means Oracle will officially own the technology powering their ESSO product instead of having to "repaint" it red & white. You might also see quicker turnaround times in getting your queries answered and your support calls resolved, so I suppose that's a plus.
Congratulations to all the Passlogix gals and guys.
Thursday, September 16, 2010
IBM just became a serious GRC player
IBM just announced that they are acquiring OpenPages and it will become part of their Business Analytics and Optimization division (which came into being because they acquired Cognos and SPSS some time ago and have since added Coremetrics and Unica to). For those who are unaware, OpenPages is a serious player in the Enterprise GRC space.
I'm not planning on analysing this to the nth degree because I'm not an expert on Business Intelligence (or Analytics as IBM calls it), but I do know a little something about Governance, Risk and Compliance (GRC).
As I mentioned previously, OpenPages is actually an Enterprise GRC vendor. That is, their focus is more on business and financial risk/compliance. If you're still confused, think Basel II (soon to be Basel III) rather than COBIT.
It makes sense for them to roll OpenPages into the Business Analytics group. But this also means that it is unlikely that the other software brands will get to have very much to do with it. I'm naturally thinking about my old mates from Tivoli here.
That said, there's actually only a very thin, dotted line that can be drawn from OpenPages to Tivoli. To make that dotted line a solid one, IBM needs to add another piece to their arsenal: IT GRC, specifically the type that links GRC to Identity and Access Management.
I'm almost certain that there are a few IT GRC (especially the Identity-centric ones) vendors that IBM Tivoli has their eye on. It's only a matter of time before they acquire one for my old mates to sell. I wonder if the relevant product teams at Oracle and CA (whom I've spoken to in the past) are sitting up a little straighter at their desks today (side note: if anyone at CA is listening, it was REALLY difficult to find a link to CA GRC Manager from your website - I almost wondered if you discontinued it).
I'm not planning on analysing this to the nth degree because I'm not an expert on Business Intelligence (or Analytics as IBM calls it), but I do know a little something about Governance, Risk and Compliance (GRC).
As I mentioned previously, OpenPages is actually an Enterprise GRC vendor. That is, their focus is more on business and financial risk/compliance. If you're still confused, think Basel II (soon to be Basel III) rather than COBIT.
It makes sense for them to roll OpenPages into the Business Analytics group. But this also means that it is unlikely that the other software brands will get to have very much to do with it. I'm naturally thinking about my old mates from Tivoli here.
That said, there's actually only a very thin, dotted line that can be drawn from OpenPages to Tivoli. To make that dotted line a solid one, IBM needs to add another piece to their arsenal: IT GRC, specifically the type that links GRC to Identity and Access Management.
I'm almost certain that there are a few IT GRC (especially the Identity-centric ones) vendors that IBM Tivoli has their eye on. It's only a matter of time before they acquire one for my old mates to sell. I wonder if the relevant product teams at Oracle and CA (whom I've spoken to in the past) are sitting up a little straighter at their desks today (side note: if anyone at CA is listening, it was REALLY difficult to find a link to CA GRC Manager from your website - I almost wondered if you discontinued it).
Tuesday, September 14, 2010
Can't we just have a normal flat-screen?
Remember when everyone was getting excited (e.g. TechCrunch, Mashable, All Facebook) about Facebook allowing automatic login using OpenID? While they didn't accept just any OpenID, apparently a handful of well known OpenID providers would work. One of these approved providers was Google (using Gmail).
I dutifully linked my Gmail account to Facebook, logged out of Facebook, logged into Gmail, opened a new browser tab and navigated to Facebook. I waited. And I waited some more. I closed my browser and tried it again. I didn't think it would help but I suppose I was simply doing what Microsoft had programmed into my head from the many years of using Windows; when in doubt, reboot (I use a Mac now, so I wasn't going to go the whole hog and reboot my machine). It still didn't work. So now Facebook had a link between my Facebook account and my Google account without providing me with any benefit. I put it down to a bug or a misconfiguration but didn't care enough to persist. After all, I'd read that other people managed to get it working.
The keyword here is 'automatic'. Facebook's interface does not have a 'use your OpenID to login' link, hence it is important that it be automatic if they want to leverage an external mechanism like OpenID because there is no way for the user to initiate the sign on.
I revisited this supposed feature of Facebook recently because we were doing some testing with Facebook's supposed OpenID capabilities and after some investigation, realised it was still broken. That is, Facebook does not function as an OpenID relying party, even when using Gmail as the provider.
From what we can gather (by reading various bits and pieces), Facebook's auto-login relies on the existence of a browser cookie from its list of approved OpenID providers. In other words, it's a bit of a hack. Of course, they didn't have many other options as OpenID doesn't specify a way to perform automated checking for a user being logged into their identity provider. The obvious problem being that there are a multitude of potential identity providers and this can include ones that the relying party does not know about (side note: this isn't as much of an issue in an enterprise federated context because relying parties usually know where to redirect the user because there is typically only a single-trusted identity provider, which means the user gets automatic single sign-on if they are already signed-in to the identity provider).
I bring up automatic login and Facebook because I came across a rather interesting way that the people over at StackExchange (if you've ever visited StackOverflow, that's them) have chosen to tackle the issue across their network of sites: they are making use of HTML5 Local Storage instead of relying on crappy (and often insecure) browser cookies.
Reading between the lines, the issue they had was a common one many organisations run into. They have a network of sites that use separate identity stores and they wanted to be able to give their users seamless single sign-on while not compromising on usability. The stock standard answer from those in the vendor world would have been: "just use our Federated Identity Manager". Throwing SAML (I'll be referring to SAML throughout this post, but I really mean 'SAML or a similar open standard') at their problem would have worked. But they ended up rolling their own solution.
The open standards zealots out there would be chastising StackExchange for not using a well known, standard to solve their issue. But herein lies to the problem with what we refer to as Enterprise Federated Identity: it's too complicated for many situations. Unfortunately, a common issue is that OpenID on its own doesn't cut it.
StackExchange chose a hybrid model. They leveraged OpenID and layered additional security measures on top of it. While I haven't had the time to analyse their implementation in minute detail, they look to have designed a fairly sound solution. The obvious potential hole relates to how they store their data using HTML5 Local Storage, but at least it's an improvement on using browser cookies (because cookies are sent over the wire while HTML5 Local Storage stays on the client machine).
Of course, if StackExchange ever wants to federate with an external 3rd party, they're going to have to embrace SAML or force the 3rd party to conform to their home-grown solution (unlikely). But as long as their requirements remain within the realms of federating across internal sites, their solution should work.
The use case for federating internally within organisations comes up more often than not. And SAML always looks like a really simple solution when an architect is drawing it all up on a whiteboard. But wait until you talk to the poor grunts who have to make it all work and get their hands dirty (or until you see the invoice for the services).
I'm not advocating that everyone should roll their own federated identity solution. In a perfect world where costs and time are non-determining factors, we would all pick SAML. But we live in the real world and all I'm saying is I understand why organisations (like StackExchange) choose to disregard SAML. This also goes some way towards explaining why Enterprise Federated Identity hasn't taken off the way we all hoped it would. After all, the reasons to use SAML make sense right? Yeah but...
The well-known federated standards we have today are like:
I dutifully linked my Gmail account to Facebook, logged out of Facebook, logged into Gmail, opened a new browser tab and navigated to Facebook. I waited. And I waited some more. I closed my browser and tried it again. I didn't think it would help but I suppose I was simply doing what Microsoft had programmed into my head from the many years of using Windows; when in doubt, reboot (I use a Mac now, so I wasn't going to go the whole hog and reboot my machine). It still didn't work. So now Facebook had a link between my Facebook account and my Google account without providing me with any benefit. I put it down to a bug or a misconfiguration but didn't care enough to persist. After all, I'd read that other people managed to get it working.
The keyword here is 'automatic'. Facebook's interface does not have a 'use your OpenID to login' link, hence it is important that it be automatic if they want to leverage an external mechanism like OpenID because there is no way for the user to initiate the sign on.
I revisited this supposed feature of Facebook recently because we were doing some testing with Facebook's supposed OpenID capabilities and after some investigation, realised it was still broken. That is, Facebook does not function as an OpenID relying party, even when using Gmail as the provider.
From what we can gather (by reading various bits and pieces), Facebook's auto-login relies on the existence of a browser cookie from its list of approved OpenID providers. In other words, it's a bit of a hack. Of course, they didn't have many other options as OpenID doesn't specify a way to perform automated checking for a user being logged into their identity provider. The obvious problem being that there are a multitude of potential identity providers and this can include ones that the relying party does not know about (side note: this isn't as much of an issue in an enterprise federated context because relying parties usually know where to redirect the user because there is typically only a single-trusted identity provider, which means the user gets automatic single sign-on if they are already signed-in to the identity provider).
I bring up automatic login and Facebook because I came across a rather interesting way that the people over at StackExchange (if you've ever visited StackOverflow, that's them) have chosen to tackle the issue across their network of sites: they are making use of HTML5 Local Storage instead of relying on crappy (and often insecure) browser cookies.
Reading between the lines, the issue they had was a common one many organisations run into. They have a network of sites that use separate identity stores and they wanted to be able to give their users seamless single sign-on while not compromising on usability. The stock standard answer from those in the vendor world would have been: "just use our Federated Identity Manager". Throwing SAML (I'll be referring to SAML throughout this post, but I really mean 'SAML or a similar open standard') at their problem would have worked. But they ended up rolling their own solution.
The open standards zealots out there would be chastising StackExchange for not using a well known, standard to solve their issue. But herein lies to the problem with what we refer to as Enterprise Federated Identity: it's too complicated for many situations. Unfortunately, a common issue is that OpenID on its own doesn't cut it.
StackExchange chose a hybrid model. They leveraged OpenID and layered additional security measures on top of it. While I haven't had the time to analyse their implementation in minute detail, they look to have designed a fairly sound solution. The obvious potential hole relates to how they store their data using HTML5 Local Storage, but at least it's an improvement on using browser cookies (because cookies are sent over the wire while HTML5 Local Storage stays on the client machine).
Of course, if StackExchange ever wants to federate with an external 3rd party, they're going to have to embrace SAML or force the 3rd party to conform to their home-grown solution (unlikely). But as long as their requirements remain within the realms of federating across internal sites, their solution should work.
The use case for federating internally within organisations comes up more often than not. And SAML always looks like a really simple solution when an architect is drawing it all up on a whiteboard. But wait until you talk to the poor grunts who have to make it all work and get their hands dirty (or until you see the invoice for the services).
I'm not advocating that everyone should roll their own federated identity solution. In a perfect world where costs and time are non-determining factors, we would all pick SAML. But we live in the real world and all I'm saying is I understand why organisations (like StackExchange) choose to disregard SAML. This also goes some way towards explaining why Enterprise Federated Identity hasn't taken off the way we all hoped it would. After all, the reasons to use SAML make sense right? Yeah but...
The well-known federated standards we have today are like:
- A full-sized movie theatre screen (SAML and its variants)
- A hand-held television (OpenID).
Subscribe to:
Posts (Atom)