Category Archives: SOA

HTTP PUT vs LDAP Modify

Posted on April 26, 2013 | Leave a comment

The StormPath blog has an interesting article exploring HTTP PUT vs POST in REST based APIs for managing identity information. The article is interesting and worth reading, but misses the bigger picture. It points out that both HTTP PUT and POST can be used for sending updates in a REST API, but the HTTP spec mandates the HTTP PUT be idempotent. The idempotent requirement dictates that for an HTTP PUT, all values must be sent on the request, not just the ones being modified by the client.

Now I am sure idempotent PUT operations are important to people that design ways to update html documents. But I’m not in that business and neither are you. I am in the business of designing and enabling distributed identity systems, and in that business you never send a modification request that passes data you don’t need to modify. Simply put, you have to assume multiple concurrent updates to the backend data.

Put another way the article could simply have said “Never use HTTP PUT for data modification”. And herein lies the most important lesson of REST APIs: the REST mechanism is the means by which to build distributed systems, not an end to itself. The fact that you are using REST does not obviate the principals of basic distributed system design.

Oh, but it gets worse. Assuming your data model is attribute-value based, some of those attributes are going to be multi-valued attributes. Just as a client should only transmit the attributes that are modified, it should also only transmit the value modifications for multi-valued attributes.

That’s why LDAP Modify works as it does. One common mistake developers make using LDAP is not doing proper multi-valued attribute updates. Likewise your REST API will not only need to support partial record updates but partials attribute value updates.

→ Leave a comment

Posted in Identity, Identity Management, LDAP, Programming, SOA, SOAP

Tagged , , , , ,

Oh really?

Posted on September 5, 2008 | Leave a comment

I love headlines. I have how they so often veer from the basic facts of the article they purport to summarize. The are wonderful flights of fancy. For instance on Yahoo news there was this breathless headline:

Chrome Will Enhance SOA in the Enterprise

Oh really? “Will” you say? No qualifiers, no doubts? Of course the article itself was much more circumspect than that:

Google Chrome may be the fastest browser around, but it may actually prove to be even more important to the enterprise for its ability to interact with service-oriented architectures (SOA).

At least, that’s the way a number of SOA pundits see it.

Here is how I see it. The Archie and Jughead Browser will not be a factor in the enterprise for several years, if it all. There are two reasons for this, infrastructure and testing.

Deploying enterprise apps that leverage whatever nice features Chrome has requires that the it be deployed to each desktop. Over time there will also be the requirement to make sure everyone is on the correct version of Chrome. Eventually you will have a situation where two different enterprise web applications would only officially support different versions of Chrome.

Wasn’t this avoiding this pain one of the reasons we moved to web apps to begin with?

So what about enterprise web applications that will support IE, Firefox, and Chrome? That may eventually happen, but it won’t be for a long time, because of testing. What vendor, or in-house dev team, wants to add another column to their test matrix? They will do it, but only when Chrome support becomes a selection criteria.

None of this means Chrome won’t be a huge hit among consumers for home use. I hope it does because it makes things more interesting.

But in the enterprise? Don’t hold your breath.

→ Leave a comment

Posted in Google, SOA, Software

Tagged , ,

Identity Infrastructure or Duct Tape?

Posted on May 7, 2008 | Leave a comment

Radovan Semančík has some interesting thoughts on this recent Identity Bus discussion. Radovan sees a whole lot of Duct Tape:

All the “buses” are just that. A duct tape. The best product for temporary fixes ever made. But you cannot really build an infrastructure on duct tape, can you?. How you would make a water supply system for a big city using a duct tape? How long can that last? Can you duct tape an electricity distribution system?

 My question is if all these buses go somewhere. What is the systemic solution that we want to achieve? What is our vision? Where we want to go? As the Cheshire Cat observed, if we do not know where we want to go it does not matter which road we take.

On the one hand I think Radovan is too hung up on the name “Identity Bus”. I think what we are discussing here is more of an Identity Layer that is intended to be ubiquitous in an enterprise infrastructure. Of course as I have pointed out before, we already have that in AD. What we are discussing is how to improve on that.

On the other hand Radovan is spot-on about one of my frustrations about the Identity Bus discussion. There is not nearly enough discussion about what such a system would actually do. So far the general consensus seems to be that an Identity Bus is:

  • Enterprise Ubiquitous (i.e. an Identity Layer)
  • Based on Claims and Claims Transformation
  • Multi-protocol (i.e. supports LDAP, SAML, XACML, SPML, etc)
  • Supports both push and pull models

 OK, fine. Those are all laudable goals. But what exactly are we going do with all that? Is this a solution looking for a problem or is there a real vision? Is the Identity Bus a real infrastructure, or is it duct tape?

BTW: Why is duct tape like the Force? There is a light side and a dark side and it binds the Universe together.

→ Leave a comment

Posted in Identity, Identity Bus, Identity Management, Provisioning, SAML, SOA, SPML

Tagged , ,

I have failed to communicate

Posted on April 16, 2008 | 1 Comment

Clayton Donley of Oracle makes some excellent points here about my “Elephant in the Room” post.  But I have apparently done a poor job in communicating the whole point of the post. In his post:

What I think his post misses is the fact that most LDAP access in most applications is poorly written, even when using ADSI or ADO to talk natively to Active Directory. I can’t count the number of virtual directory deployments that we’ve sold to help customers in environments that were nearly 100% Microsoft (ADO/ADSI-enabled apps talking to Microsoft AD). Many of these deployments were to get around bad schema assumptions, others were to get around topology issues or forest boundary issues.

While we sell virtual directory technology, we hate making our customers pay money to solve such tactical issues. We want to be layering on higher-order value.

So when Phil Hunt or others talk about the Liberty IGF project, what they’re really saying is that we want a better way to give application developers a way to code something in a way they understand and can do well rather than a native access protocol that requires specialization. So while LDAP isn’t going away and everything from virtual directories to identity buses will need to support native access over LDAP to be successful, not looking at what developers are learning and using every day would be a mistake.

Keep in mind that developers must integrate with a LOT of technologies to build an enterprise application or portal. For example, a portal may be integrating with HR, CRM, and ERP systems. That integration is increasingly happening via web services. Giving these developers a mandate to use a completely different type of technology to integrate identity will only make identity more specialized and less standardized and understood over time. That is a recipe for disaster.

I did not mean to imply LDAP was a better choice that Liberty IGF. I was in fact the BMC rep to Liberty TEG and am very supportive of their work. I also agree there are a lot of problems with LDAP and how developers use it.

But having been involved at some level in the standardization efforts of DAML, XRPM, DSML v2, SPML, SAML, WSDM, OATH, Liberty, WS-Trust, WS-SecureConversation, and WS-Federation. I have spent a lot of time working on identity service standards and developing implementations of those standards at several different companies.

But the hardest thing is getting adoption of these standards. The point of my post was not to suggest that standards for identity services other than LDAP aren’t a good thing. The point was that to drive adoption you have to accept the reality that AD and other LDAPs have the predominant mind-share today.

To many enterprises, LDAP is their one identity hammer. And they see all their identity problems as nails. If we want them to put down the LDAP hammer and pick up the IGF pneumatic impact wrench, we have to explain to him in real world business cases why it’s better. Because they  know the LDAP hammer will work and they already have it in their tool box. The IGF pneumatic impact wrench is a strange new tool to him that they must first understand and second justify purchasing.

Of course AD isn’t all identity in an enterprise. But for extranet identities you will have to justify why IGF or some other identity service is better than just throwing in an ADAM, OID,  or OpenLDAP instance. Or even a virtual directory like OVD or OptimalIdM VIS (for the .NET centric customer). The enterprise architects know they already have a wide variety of tools and APIs to leverage LDAP. They don’t yet have those for IGF and other identity services.

Bottom line – identity services will not reach the level of adoption to where you could say there is an “Identity Bus” until there are compelling business cases made for it. Enterprises not only have to adopt the identity service standards, but they need to make vendor support of those standards a selection criterion to drive adoption.

→ 1 Comment

Posted in BMC Software, Identity, Identity Management, OATH, SAML, SOA, SPML, Standards, WS-Trust

Tagged , , , , ,

The elephant in the room

Posted on April 10, 2008 | 4 Comments

In the latest installment of the Great Meta-Virtual-Directory-Identity-2.0-Bus-Hub Debate, Dave Kearns is groping elephants. Dave allows that we are all really talking about the same Meta-Virtual-Directory-Identity-2.0-Bus-Hub, but like the three blind men and the elephant, we just can’t agree we are all groping the same animal.

Kim Cameron elaborates what features needed for the Meta-Virtual-Directory-Identity-2.0-Bus-Hub. Kim’s requirements:

  • By “next generation application” I mean applications based on web service protocols.  Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP. 
  • Developers and users need places they can go to query for “core attributes”.  They must be able to use those attributes to “locate” object metadata.  Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
  • Applications need to be able to register the information fields they can serve up. 

Today’s virtual directories just don’t do this any better or any worse than metadirectories do.  Virtual directories expose some of the fabric, just as today’s metadirectories do, but they don’t get at the big prize.  It’s what I have called the unified field of information.  Back in the 90’s more than one analyst friend made fun of me for thinking this was possible.  But today it is not only possible, it is necessary.

Phil Hunt throws in his requirements Meta-Virtual-Directory-Identity-2.0-Bus-Hub:

  • There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
  • Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of “authoritativeness”. Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn’t authoritative over an attribute, it probably shouldn’t be storing or managing that attribute. Instead, this “non-core” attribute should be obtained from the “identity network” (or metaverse as Kim calls it). An application’s “core” data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  • Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application’s requirements.

Since Dave first brought up elephants, let me point out the elephant in the room no one is talking about; AD. For the vast majority of enterprises AD plus other identity services already serves the role of the identity hub. It is your company’s identity store, authentication service, authorization service, and attribute service. It is used to identity enable your remote access gateways and your email servers. If you are using a Virtual Directory, chances are AD is at least one of the stores behind it. Other companies such as Quest and Centrify have developed products to extend AD authentication to wide range of heterogeneous OSs.

Vendors have created products for provisioning from AD out to disparate systems. When I started at Access360 AD didn’t exist yet and our strategy was to get the buy-in from HR up front because the HR system was the source of all identity information. By the time I started doing provisioning at OpenNetwork Technologies, we assumed that customer already had an HR feed into AD.

While I like both Kim and Phil’s vision of what a Meta-Virtual-Directory-Identity-2.0-Bus-Hub should be, the big question customers are going to ask is why? Companies have spent an incredible amount of money building out AD as their identity hub. What specific cost saving or new capabilities will they achieve by implementing this vision?

Kim thinks web services are the answer. But what specific web services and what specific advantages do they offer? Will they be easier to adopt than LDAP? If we think LDAP hard for developers, wait till we try explaining WS-CombinatorialExpansion. 

Phil thinks a key requirement is to abstract the protocols and schemas. Is that really an important requirement given the near ubiquity of AD?

I know this isn’t pleasant to hear, but AD is the incumbent. It’s nearly everywhere. It’s scalable to millions of users. The LDAP protocol is efficient and mature. It’s supported by countless applications. Before a customer considers displacing or adding another identity layer on top of AD they are going to need real cost savings or additional capabilities and order of magnitude over what they have now.

That’s not to say LDAP is the perfect solution or even the best solution. But if we are going to propose a better one we have to say specifically why it’s better. With real examples that customers can relate to. With cost savings and capabilities they can’t reach today with AD.

→ 4 Comments

Posted in Authentication, Identity, Identity Management, Provisioning, SOA, Web Services

Tagged , , , ,

The secret is, as it always has been, to provide value and not promises

Posted on March 11, 2008 | Leave a comment

Jackson Shaw ignited quite a kerfuffle with his “The Metadirectory is Dead!” post. He follows up here with some more thoughts and is spot on with this observation:

Active Directory, other directories and metadirectory “engines” will hopefully become dial tone on the network and won’t be something that has to be managed – at least not to the level it has to be today.

We are still working with provisioning technologies that were built in the 90′s. These technologies haven’t changed much. With services to license ratios still in the 5:1 to 10:1 range we clearly haven’t been successful from a software perspective.

Fellow former Access360 coworker Ian Glazer has this humorous answer to Jackson. Dave Kearns once again flogs the tired old meta-directory versus virtual directory debate.

I completely agree with Jackson that most IdM deals are way too expensive, take too long, and involve too many services. I always say, “Customers want to buy a product, not a project.” Where I disagree with both Jackson and Dave is why. I don’t believe it has anything to do with how old the technology is or whether it’s meta-directory, virtual directory, or SOA based.

The problem with most IdM deployments are three-fold from my experience:

1)      Most enterprise software is not designed with management (identity or otherwise) in mind. Customers are unwilling to take management capabilities into serious consideration when selecting enterprise software so enterprise vendors have no incentive to make it a priority.

2)      The big IdM platforms are too complicated and too hard to install, configure, and maintain. Some of this is due to poor engineering, but a lot of it is due to trying to merge independently developed products together into one solution suite.

3)      Many of the big IdM vendors aren’t really serious about IdM as a product unto itself. They see IdM as a beachhead they must control to sell their other products or services. This drives them to over-promise which invariably leads to failed deployments and unhappy customers.

Most enterprise customers don’t want to be in the Identity 2.0 business. They don’t even want to be in the Identity 1.0 business. What they want are solutions to address specific needs at a reasonable cost.

Perhaps the future of enterprise IdM belongs to companies like Microsoft, Optimal IdM, Vintela (Quest), and Approva. Companies that are trying to provide value around specific pain points rather than trying to push a comprehensive suite solution.

→ Leave a comment

Posted in Identity, Identity Management, Provisioning, SOA

Tagged , , , , , , ,

Where is Microsoft going on identity?

Posted on March 7, 2008 | Leave a comment

There has been some interesting news on Microsoft and Identity recently. Of course there is the recent acquisition o f U-prove. You can read Stefan Brands’ thoughts here and Kim Cameron’s here. I think that this is in theory a great move for Microsoft that could be very beneficial to the internet at large.

The real question is whether the theoretical benefits will ever realized by significant relying party adoption. As with SAML, OpenID, and Information Cards/Cardspace, it doesn’t matter how good the idea is or how many vendors back it, if popular relying parties don’t adopt it, it will remain an interesting topic of conversation and nothing more. I hope this catches on, I am just not betting on it.

There have been some interesting discussion going on at DEC (which I missed unfortunately). John Fontana has articles on it here, here, and here. There are three interesting thoughts here; Microsoft’s notion of an Identity Bus, opening the door to more standards adoption, and IdM as a service.

Of the three I think the notion of standards adoption is the most interesting to me personally since I have been involved in a lot of these standards activities. I would love to see Microsoft add support for the SAML protocol, XACML, and SPML.

Interesting times.

→ Leave a comment

Posted in Cardspace, Identity, Identity Management, ILM, Microsoft, OpenID, Provisioning, SAML, SOA, SPML, Standards

Tagged , , , , , ,

Jeff the Bard on Self-Issued Cards

Posted on November 2, 2007 | Leave a comment

Never read your child Dr. Seuss and then stay up late writing about Information Cards. You might have a nightmare that goes something like this (with apologies to Theodor Seuss Geisel)

Bard is Jeff
Bard is Jeff
Jeff is Bard

That Jeff-the-Bard!
That Jeff-the-Bard!
I do not like
that Jeff-the-Bard!

Do you like
self-issued cards?

I do not like them,
Jeff-the-Bard.
I do not like
self-issued cards.

Would you like them
here or there?

I would not like them
here or there.
I would not like them
anywhere.
I do not like
self-issued cards.
I do not like them,
Jeff-the-Bard.

Would you use them
in your house?
Would you use them
with your mouse?

I do not like them
in my house.
I do not like them
with my mouse.
I do not like them
here or there.
I do not like them
anywhere.
I do not like self-issued cards.
I do not like them, Jeff-the-Bard.

Would you use them
‘cause of SOX?
Would you use them
with Firefox?

Not ‘cause of SOX.
Not with Firefox.
Not in my house.
Not with my mouse.
I would not use them here or there.
I would not use them anywhere.
I would not use self-issued cards.
I do not like them, Jeff-the-Bard.

Would you? Could you?
At a bank?
Use them! Use them!
I’ll be frank!

I would not,
could not,
at a bank.

You may like them.
I’ve been shown.
You may like them
on a phone!

I would not, could not on a phone.
Not at a bank! You leave me alone.

I do not like them ‘cause of SOX.
I do not like them with Firefox.
I do not like them in my house.
I do not like them with my mouse.
I do not like them here or there.
I do not like them anywhere.
I do not like self-issued cards.
I do not like them, Jeff-the-Bard.

A blog! A blog!
A blog! A blog!
Could you, would you,
on a blog?

Not on a blog! Not on a phone!
Not at a bank! Jeff! Leave me alone!

I would not, could not, ‘cause of SOX.
I could not, would not, with Firefox.
I will not use them with my mouse.
I will not use them in my house.
I will not use them here or there.
I will not use them anywhere.
I do not use self-issued cards.
I do not like them, Jeff-the-Bard.

Say!
With Explorer?
There in Explorer!
Would you, could you, with Explorer?

I would not, could not,
with Explorer.

Would you, could you, with Safari?

I would not, could not,
with Safari.
Not with Explorer. Not with Safari.
Not at a bank. Not on a phone.
I do not like them, Sam, you’ve known.
Not in my house. Not ‘cause of SOX.
Not with my mouse. Not with Firefox.
I will not use them here or there.
I do not like them anywhere!

You do not like
self-issued cards?

I do not
like them,
Jeff-the-Bard.

Could you, would you,
with OpenID?

I would not,
could not,
with OpenID!

Would you, could you,
in Liberty?

I could not, would not, in Liberty.
I will not, will not, with OpenID.
I will not use them richer or poorer.
I will not use them with Explorer.
Not with Explorer! Not on a phone!
Not at a bank! You leave me alone!
I do not like them ‘cause of SOX.
I do not like them with Firefox.
I will not use them in my house.
I do not like them with my mouse.
I do not like them here or there.
I do not like them ANYWHERE!

I do not like
self-issued cards!
I do not like them,
Jeff-the-Bard.

You do not like them.
So you say.
Try them! Try them!
And you may.
Try them and you may, I say.

Jeff!
If you will let me be,
I will try them.
You will see.

Say!
I like self-issued cards!
I do! I like them, Jeff-the-Bard!
And I would use them in Liberty.
And I would use them with OpenID…

And I will use them as I log.
In with Explorer. And on a Blog.
And at a bank. And on a phone.
They are so good, so good, you’ve know!

So I will use them ‘cause of SOX.
And I will use them with Firefox.
And I will use them in my house.
And I will use them with my mouse.
And I will use them here and there.
Say! I will use them ANYWHERE!

I do so like
self-issued cards!
Thank you!
Thank you,
Jeff-the-Bard!

(Mirrored from TalkBMC)

→ Leave a comment

Posted in Authentication, BMC Software, Cardspace, Identity, Identity Management, Information Card, OpenID, Security, SOA, Standards, Web 2.0

Tagged , , , , , ,

Interesting SPML Articles

Posted on October 1, 2007 | Leave a comment

My friend and coworker (at both BMC and Access360) Raj Sodhi sent me an interesting SPML article by Manivannan Gopalan on SYS-CON. It’s a good overview of SPML. Raj also sent me this blog post by Martin Raepple and this page of SPML resources on the SDN.

(Mirrored from TalkBMC)

→ Leave a comment

Posted in BMC Software, Identity, Identity Management, Provisioning, SOA, SPML

DSML Revisited

Posted on August 12, 2007 | Leave a comment

There was an interesting article on DSML recently (I ran across it in Dave Kearn’s IdM Journal). This is a useful summary, but unfortunately the article mixed in references to DSML v1 and DSML v2 in a way that will likely be confusing.

Just to clear this up, DSML v1 was a private vendor spec originally initiated by Bowstreet.com. DSML v2 is an OASIS Standard. There are some key differences DSML v1 only supported representing LDAP data and schema in XML but did not address web services. DSML v2 addressed web services. The two specifications are not compatible. The free DSML tools mentioned in the article are actually DSML v1 tools.

DSML v2 is supported by some of the main LDAP Vendors. DSML interfaces to LDAP servers include the Microsoft DSML Services for Windows (DSFW), the Netscape DSML Gateway, and the Novell DSML Support. Microsoft has also added DSML support to its .NET 2.0 Directory Services, although I haven’t had a chance to play around with it.

I had some peripheral involvement in the DSML v2 effort. While at Access360 I designed the new protocol for the enRole IdM server to communicate with the enRole provisioning agents. I create an XML/HTTPS protocol that was called the Directory Access Markup Language (DAML). DAML was basically a web services layer on top of DSML v1. It was actually pretty cutting edge at the time; the enRole system was using an XML/HTTPS protocol for provisioning while SOAP was still in development as standard. Access360 was of course acquired by IBM and the enRole system became the Tivoli Identity Manager (TIM). I don’t know if the DAML protocol is still being used, but you are likely to still see references to it in TIM documentation.

When the DSML v2 effort started with OASIS, the Access360 DAML spec was contributed as input to DSML v2, along with the Dir-XML spec from Novell. I had some initial involvement with the DSML v2 effort, but that ended when I left Access360 and joined OpenNetwork Technologies.

But I have always been a fan of DSML, which is why (for better or worse) SPML 1.0 was based on DSML v2.

(Mirrored from TalkBMC)

, , , , , ,

→ Leave a comment

Posted in Identity, Identity Management, OASIS, SOA, SOAP, Standards, Web Services