Recently in Identity Category

I'll be heading up to Stockholm next week where I'll be presenting on BYOD. I'll be joined by others from StjärnaFyrkant, Ping Identity, PwC, Nokia, Sony, Telia, UnboundID, and my colleagues from Twobo. (I think some of the guys from Axiomatics will be around too.) You can find the full agenda here. My session is entitled "Turning your Organization into a Platform: Securely exposing data to apps running on employees' devices." During my talk, I'll present on how social media, mobile, cloud, and big data are having a "platformification effect" on organizations, forcing them to open up data and processes in new ways. I'll give a few examples of orgs who have done this, including my favorite, Pearson. As organizations undergo this shift, it is important that the APIs which they expose take into account the identity of the user who invokes them. Coupling this w/ information about the app/client, location, device, and other context, organizations can make calculated decisions about whether or not they should return the requested resources or not. In this way, BYOD and COPE are irrelevant. What's relevant is who the user is and what they are allowed to do in a given situation. I explained this in more detail in a whitepaper that you can find on Twobo's site (in English and Swedish). I also blogged about this on a few weeks ago, so check there for a bit more detail. The event is February 21, and it starts at 12:00 w/ lunch. So, come in time to grab a bite and talk about how BYOD is effecting Europe and beyond. Attendance is free, and you can find directions here.

Next month, at Nordic APIs in Stockholm, I'll also be giving a very exciting presentation about some innovative new things that we're doing at Twobo with the Janrain API. During my talk, I'll show how organizations can safely and securely use this service to integrate social media into their Web site as well as to publish back to them using a single API. I'll show how Janrain's service can be used with SiteMinder from CA to ensure that only authorized users gain access to sensitive parts of a Web site. What I'll demo allows Web site operators to uniformly consume anonymous, social and more trusted identities that are unaffected by the use or implementation of any particular upstream social network. I'll also show how Web site operators can combine Janrain's social media aggregation API and our integration with SiteMinder with other third-party tools, like Google Analytics, to use social more effectively. This event will be on March 21 at Jayway's office in downtown Stockholm. We'll be joined by presenters from Dopter, Jayway, Ping Identity, and Radio Sweden. We'll start w/ lunch at 12:00 and go till at least 16:00. (We might be joined by one or two more companies, so we may go till 17:00.) The event is free, and we are almost booked up, so RSVP today! More details on the agenda, speakers, etc. can be found on the Nordic APIs Web site.

[Disclosure: Twobo, my company, has a commercial relationship with Ping Identity, StjärnaFyrkant, UnboundID, Jayway, Dopter, CA, and Axiomatics; it also has an interest in both of these events.]
The SCIM crew descended on Paris two weeks ago for the IETF 83 meeting. We kicked it off by testing the interoperability of our SCIM implementations for the second time. (IIW last fall was the first.) We paired up about a half dozen clients with roughly the same number of servers, and ran them through two dozen use cases. Participants were there from BCPSOFT, Courion, Gluu, Nexus, SailPoint, Salesforce, UnboundID, WSO2, and I was there testing Ping's new on-demand cloud identity management service, PingOne. It was a great time, and the results were very positive.

tower.jpgThe next morning was the Birds of a Feather (BoF). Trey Drake of UnboundID and Morteza Ansari of Cisco WebEx gave an overview of SCIM 1.0, and talked through the proposed charter of an IETF Working Group (WG) that would define the next version of the protocol. I have never participated in the formation of a WG before, so the process was unfamiliar to me. I was expecting the WG to be formed on the spot, but, apparently, that's not the way it works. Instead, BoF attendees raise issues that are ironed out on the mailing list. After the issues are addressed, an IETF Area Director (AD) will decide if the WG should be formed, who should chair it, etc. This will take about 2 to 3 months, so stay tuned.

In the meantime, some of us will be chatting at EIC on a panel about SCIM, we'll be doing more interop testing at IIW 14 (or nearby), and we'll be discussing stuff on the new IETF mailing list. So, come join the growing SCIM community in Munich, San Francisco, or in cyberspace :-)

Imagine you have a scenario where you want to authenticate end users to your Web site with a consumer-grade authentication protocol like OpenID, OAuth, Facebook Connect, etc. from many different Identity Providers (IdPs). Also, suppose you need to SSO from your site to another or you want to invoke a partner's Web service that requires calls to be secured w/ a WS-Security token. For instance, imagine you have an e-commerce Web site. To increase engagement, conversion rates, yadda yadda, you want to allow customers to login w/ their Twitter, Yahoo!, Facebook, or Google accounts. When a user posts a question in your forum, which you've outsourced to a third-party, you need to SSO to that partner's site which exposes a SAML endpoint. Imagine you also want to publish the user's activity in the forum to one or more of their social networks. Tall order! How might you accomplish this? I've been wondering this, and here's my idea.

My solution leverages PingFederate and Gigya Connect (both of which are sold by companies I'm affiliated w/). Gigya Connect is used as an abstraction that hides all the IdPs and provides a unified representation of a customer. PingFederate marshals this abstract notion of the user into a SAML, WS-Federation, or WS-Trust message for SSO purposes. From a high level, we have this:


In the sketch, I am trying to show how each of the IdPs sends their own types of tokens (TT, TY, TFB, TGOOG) to Gigya which normalizes it into a Gigya token (TG). When the Web app receives this, it can send user-related info to PingFederate, and it sends a SAML message (TSAML) to the partner (i.e., the Service Provider or SP). At the SP, it can use the Gigya API and the user's ID passed in TSAML to publish activity back to Twitter, Google Buzz, FB, etc. Sounds easy when I write it all out like this, but the devil's certainly in the details on this one.

To make this work, I started w/ the HTML doc I wrote after chatting w/ David Brisebois on Twitter the other day. Literally, all I had to change was the location the form was submitted to (nice!):
<body onload="onLoad()">
    <p>Please Sign In using one of the following providers:</p>
    <div id="loginDiv"></div>
    <form method="post" action="https://idp:9031/idp/">

If you look at the whole doc, you'll see in the JavaScript that I dynamically added each of the Gigya user object's properties to the form that is being submitted to the highlighted URL. That is a special PingFederate endpoint that instructs it to start an SSO transaction.

Here's the magic:
PingFederate can't make sense of the Gigya user data, so I used its SDK to create an adapter that converts it into something it can understand and will put into a SAML assertion. The code basically loops over the form parameters dynamically added to the request in the JavaScript and hands them back to PingFederate in code like this:

public class AuthenticationAdapter implements IdpAuthenticationAdapter

    public Map lookupAuthN(HttpServletRequest request, HttpServletResponse response, ...)

        Enumeration e = request.getParameterNames();
        Map result = new HashMap<String, String>();
        while (e.hasMoreElements())
            String name = (String)e.nextElement();
            String value = request.getParameter(name);
            result.put(name, value);
        return result;


(It's a good thing the Java code wasn't much harder than this. I was a Java programmer once, but I'm not anymore, and, boy, am I glad! The tools and the verbosity of the language are dreadful IMHO.)

The class also has code in it that creates a Gigya-specific configuration GUI in PingFederate that can be used to provide my adapter w/ config data (e.g., the secret key). Here's what it looks like:


After you've configured the adapter, you need to specify what attributes will be passed in from it to PingFederate. I decided to make almost all of Gigya's user attributes extended properties. In hind sight, they should have been core attributes, especially considering my while loop above.


This forms the connection between Gigya and PingFederate. After that, it can be used to create a federation connection. This is standard PingFederation stuff; no more magic at this point.

In my case, the SAML Response send from PingFederate to the partner used the Gigya user ID as the SAML subject. This would allow the SP to not only use the values in the token, but also use the Gigya API to publish events back to the user's social networks when they perform activities there.

The ability to use Gigya and PingFederate like this is very cool and gives you a federation Swiss army knife that you can use to carve up all sorts of new business opportunities. I know that this writeup leaves a lot out and that things might not be clear, so I may make a screencast showing this in a bit more detail. In the meantime, feel free to drop me a note if you have questions.
I've started to mess around w/ Gigya's service which abstracts away the different APIs of various identity providers (IdPs) and their protocols. The unified API is a lot simpler and doesn't require a Web application to be coded to all the various protocols (e.g., OpenID, OAuth, Faceboook Connect, etc.). On top of their API, they have created a plug-in that can be added to a Web page using a little JavaScript and allows an end user to pick an IdP that they'd like to login w/.

Things can get more sophisticated if needed. For instance, I was talking w/ David Brisebois on Twitter about the widget's default behavior of redirecting the user to a page w/ the information gleaned from the IdP tacked onto the query string. Brisebios didn't like this and would have preferred that the results be posted. This is a fair grievance IMO, and his dislike gave me the chance to kick the tires a bit. After a little JavaScript refresher (it's been years!), I came up w/ this little snipped that's based on the getting started example. I thought I'd pass it on in case it helps anyone besides me and Brisebios. The complete sample can be found in my stash, but the noteworthy part is how the onLoginEventHandler is wired up to the widget and used to create form elements dynamically like this:

function onLoad()
    var conf = { APIKey: '...'};
, {
    });, {
function onLoginEventHandler(eventObj)
    for (var f in eventObj.user)
      var el = document.createElement('input');
      el.type = 'hidden'; = f;
      el.value = eventObj.user[f];

In the future, I may be blogging about other aspects of Gigya's services and show how they can be used in conjunction w/ ADFS, PingFederate, and other sorts of things that I'm always going on about on this blog. In the meantime, if you have questions on Gigya or anything else you read about on my blog, please don't hesitate to reach out to me.