The Only Two Skills That Matter: Clarity of Communications and Empathy

I meant to write a post describing how I build presentations, but I realized that I can’t do that without writing this one first.

I had the honor of working with Drue Reeves when I was at Burton and Gartner. Drue was my chief of research and as an agenda manager we worked closely in shaping what and how our teams would research. More importantly we got to define the kind of analysts we hired. We talked about all the kinds of skills an analyst should have. We’d list out all sorts of technical certifications, evidence of experience, and the like. But in the end, that list always reduced down to two things. If you have them, you can be successful in all your endeavors. The two most important skills someone needs to be successful in what they do are:

  • Clarity in communications
  • Empathy

Continue reading

Finding your identity (content) at Dreamforce

Dreamforce is simply a force of nature (excuse the pun.) There are more sessions (1,400+) then you could possibly attend even if you clone yourself a few times over. And that’s not even including some amazing keynotes. Needless to say there’s a ton to occupy your time when you come join us.

The Salesforce Identity team has been putting together some awesome sessions. Interested in topics such as single sign-on for mobile applications, stronger authentication, or getting more out of Active Directory? You need to check out our sessions!

I’ve put together a handy list of all of the identity and access management content at Dreamforce 14. Hope you find it helpful and I cannot wait to meet all of the Salesforce community grappling with identity management issues. Continue reading

Do we have a round wheel yet? Part 2 of my musings on identity standards

Yesterday I talked about the state of identity standards with regards to authentication and authorization. Today I’ll cover attributes, user provisioning, and where we ought to go as an industry.

Attributes

The wheel of attributes is roundish. There are two parts to the attribute story: access and representation. We can access attributes… sorta. There’s no clear winner that is optimized for the modern web. We’ve got graph APIs, ADAP, and UserInfo Endpoints – not to mention proprietary APIs as well. Notice I added the constraint of “optimized for the modern web.” If remove that constraint, then we could say that access to attributes is a fully solved problem: LDAP. But we are going to need a protocol that enables workers in the modern web to access attributes… and LDAP ain’t it.

As for a standardized representation, we have one. Name-value pairs. In fact, name-value pairs might be the new comma. And although NVP are ubiquitous, we don’t have a standard schema. What is the inetOrgPerson of a new generation? There is no inetOrgPerson for millennial developers to use. But does that even matter? We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.

 User Provisioning

User provisioning is nearly round. Let’s face it the wheel that SPML v2 built was not round. The example that the standard provided wasn’t even valid XML – not an auspicious start. In fact, SPML was a step away from roundness when we think about DSML v2. DSML v2 was a round wheel. It wouldn’t be very useful to day but it would roll.

So what about SCIM? I’m bullish on it. Some really smart people worked on it, including my boss. We (saleforce.com) are supporting it. Others such as Cisco, Oracle, SailPoint, Technology Nexus, and others are supporting. We hope you support it too. In fact, hopefully, at the end of this week it might just get a final version of the 2.0 draft at the IETF meeting in Toronto. SCIM definitely needs more miles on the road, but I believe that the use cases that have been used to form SCIM are fairly representative of a majority of use cases we have. It can’t do everything but better believe it can do something.

And this narrow focus is important as we think about the work we must do. As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition. Continue reading

Do we have a round wheel yet? Musings on identity standards (Part 1)

Why do human continually seem to reinvent what they already have? Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while? This is a pattern that is familiar. You have a working thing. You attempt to “fix” it and in doing so break it. You then properly fix it and get a slightly more functional thing in the end.

Why is it that we reinvent the wheel? Because eventually, we get a round one. Anyone who has worked on technical standards, especially identity standards, recognizes this pattern. We build reasonably workable standards only to rebuild and recast them a few years later.

We do this not because we develop some horrid allergy to angle brackets – an allergy that can only be calmed by mustache braces. This is not why we reinvent the wheel, why we revisit and rebuild our standards. Furthermore, revisiting and rebuilding standards isn’t simply a “make-work” affair for identity geeks. Nor is it an excuse to rack up frequent flyer miles.

Identity in transition

We reinvent the wheel the tasks needed of those wheels change. In IAM, the shift from SOA, SOAP, and XML to little s services, REST, and JSON was profound. And we had to stay contemporary with the way the web and developers worked. In this case, the technical load that our IAM wheels had to carry changed.

But there is a more profound change to the tasks we must perform and the loads we must transport and it too will require us to examine our standards and see if they are up to the task.

It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? And not just right people but also right “things” – did they get the experience (or data) they needed at the right time.

There is another transition underway. This transition is closely related to IAM’s transition from delivering and managing access to delivering and managing experience. We are being asked to haul more and different identities

We are pretty good as an industry at managing a reasonable number of identities each with a reasonable number of attributes. Surely, what is “reasonable” has increased over the years and it is fairly safe to say that no longer is a few million identities in a directly a big deal.

But how well will we handle things? Things will have a relatively few number of attributes. Things will produce a data stream that really interesting but their own attributes might not be that interesting. And, needless to say, there will be a completely unreasonable number of them: 20 billion? 50 billion? a whole lot of billions of them.

The transition of IAM isn’t just from managing identities of people carbon-based life forms to silicon ones. This transition also includes relationships. Today we are okay at managing a few relationships each with very few attributes. But what we as an industry must do is manage a completely unreasonable number of relationships between an unreasonable number of things and each of these relationships has a fair number of attributes of their own.

That, my friends, is a heavy load to haul. And so it is worth spending a little time considering if our identity standards wheels are round. Let’s look at 4 different areas of IAM to see if we have round wheels:

  1. Authentication
  2. Authorization
  3. Attributes
  4. User provisioning

Continue reading

The Laws of Relationships (A Work in Progress) In Progress

A few weeks back I had the pleasure of delivering my ideas for the Laws of Relationships. The Laws are meant to be design considerations to everyone building, deploying, or consumer identity relationship management services. The team at ForgeRock, our hosts at the IRM Summit, were kind enough to video the talks. What follows is both a video of my delivery as well as the slides themselves. I am very much interested in getting feedback on this. I want to channel the response into the Kantara Initiative Working Group that is forming around IRM.

 

Laws of Relationships v5.001

The Laws of Relationships (A Work In Progress)

Here it is… week 10 of my new job at salesforce.com. Needless to say it has been a bit of a blur. Part of my gig here is to hit the speaking circuit. I was at the European Identity Conference a few weeks ago talking about killing off IAM and how it should be reborn, and next week I am off to the Identity Relationship Management Summit. I have to say, I am little nervous about speaking at IRM this year… not one, but two of my ex-bosses will be speaking there, not to mention my current one.

I have to admit when I first heard the noise surrounding Identity Relationship Management, I cringed, especially when people started referring to it as IRM. IRM sounds way too much like DRM to me and that just leads to bad things. Furthermore, my concerns with what Kantara and ForgeRock laid out was that it didn’t necessarily address relationship management; they presented the needs of modern IAM well but didn’t present the needs of relationship well. However, after many conversations and email threads, I still loathe the IRM name but have come around to the larger mission that Kantara has in mind. Simply put, relationship management is the future of identity and access management.

The Laws of Relationships (A Work In Progress)

Taking a page from the work that Kim did with “The Laws of Identity,” I wanted to provide the starting point for the community to build a similar set of design constraints and considerations for relationships and relationship management technologies. Our current IAM methods will be insufficient in a near future in which we are dealing with an unreasonable number of people and things and the relationships between them. At the IRM Summit, I’ll be presenting a strawman set of laws for relationships to help us think about this coming future. To that end, here is a preview of the laws (and axioms and attributes) of relationships. Continue reading

Anyone can kill off a protocol a.k.a XACML isn’t dead

There’s a little bit of a kerfuffle going on in XACML-land. A non-Gartner analyst made the claim that XACML is dead. Such a claim doesn’t go unnoticed; so Gerry, Anil, Danny, and Remon have all responded that no, XACML isn’t dead. It is not pining for the fjords. It isn’t even zombified.

Anyone can declare a protocol dead. Last year it was SAML. This year, apparently, it’s XACML. Now as someone who killed off the entire IAM industry, I think I’m in a position to comment about this.

It’s easy to say X is dead. SAML, SPML, DSML – doesn’t matter – you declare it dead, write your blog post, and call it a day. But what’s hard to do, and what is necessary to do, is, if you kill something off, you have to offer an alternative. In the case of IAM, I believe we are seeing the hazy outline of what it will become reborn as start to emerge: something more nimble, developer-friendly, and more indistinguishable from business services.  In the case of XAMCL, no alternative was provided.

Just a few things to keep in perspective when thinking about XACML. First, separate externalized authorization management (EAM) from XACML. Enterprises have been doing EAM for decades. The pattern of using something like RACF as a decision-as-a-service facility is a well established practice. Although enterprises may not be using XACML, they are doing EAM and that will only continue.

Continue reading

spots of thoughts: ian and friends rant, rave, and ruminate