Category Archives: WS-Trust

Office365 announcement

OptimalIdM announced its new Office365 offering this morning. You can read the announcement here.

This has been an great project to work on. OptimalIdM can now enhance Office365 with a great set of new features and can do so for both the WS-Federation Passive and Active profiles. The Active Profile is used for Office365 Lync and Outlook support.

The new features we add to Office365 include easy multi-forest support, support for non-AD users, support for users with non-addressable UPNs, two-factor authentication, auditing, and a whole bunch of other features.

Exciting times!

Microsoft and SAML 2.0

According to Don Schmidt Microsoft is finally going to support SAML 2.0:

At the Professional Developers Conference this week Microsoft is announcing the beta release of “Geneva”, the codename for its new claims based access platform.  This platform helps developers and IT professionals simplify user access to applications and other systems with an open claims-based model.  “Geneva” helps developers to externalize user authentication and identity processing from application code by using claims that are obtained with pre-built security logic that is integrated with .NET tools.  “Geneva” helps IT professionals to efficiently deploy and manage new applications by reducing user account management, promoting a consistent security model, and facilitating seamless collaboration across departmental, organizational and vendor boundaries.  User access benefits include shortened provisioning lead times, reduced accounts, passwords and logins, and enhanced privacy support.  “Geneva” implements the Identity Metasystem vision for open and interoperable identity, and includes built-in support for standard federated identity protocols.

A fundamental goal of “Geneva” is to extend the reach of its predecessor, Active Directory Federation Services, and provide a common identity programming model for developers of both web applications and web services.  To maximize interoperability with clients and servers from other vendors, it supports the WS-Trust, WS-Federation and SAML 2.0 protocols.  To maximize administrative efficiency “Geneva” automates federation trust configuration and management using the new harmonized federation metadata format (based on SAML 2.0 metadata) that was recently adopted by the WSFED TC.

This is very interesting. It looks like in the Geneva release what was ADFS will now support SAML 2.0 along with WS-Federation. It also looks like Cardspace, Zermatt, and ADFS are going to be combined into a single “platform”.

Interesting times.

I have failed to communicate

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.

Interesting Combination of OpenID and Information Cards

From Mike Jones there is this post about a Sxip proposal to combine OpenID with Information Cards. I have only given it a cursory glance so far, so I am not sure what I think yet. It does seem compelling because using Information Cards overcomes some of the issues around OpenID while still preserving the ability to do trust based on URL ownership.

What’s really interesting about this is that it doesn’t use SAML 1.1 tokens. It uses a OpenID Specific token in the RSTR. I gave it a quick try and it worked smoothly using the following token in the RSTR:

<openid:OpenIDToken xmlns:openid=”http://specs.openid.net/auth/2.0″>openid.ns:http://specs.openid.net/auth/2.0
openid.op_endpoint:https://openidcards.sxip.com/op/
openid.claimed_id:https://openidcards.sxip.com/i/jbohren
openid.response_nonce:2007-08-27T12:13:31Z0
openid.mode:id_res
openid.identity:https://openidcards.sxip.com/i/jbohren
openid.return_to:https://openidcards.sxip.com/demorp/
openid.assoc_handle:e88bb8e5c4577c85
openid.signed:op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle
openid.sig:S4TcYfUDeUOIiCg0idtmJYijKGQ=
openid.ns.ext1:http://openid.net/srv/ax/1.0-draft4
openid.ext1.mode:fetch_response
</openid:OpenIDToken>
I will have to dig into this some more. It does look very interesting.

(Mirrored from TalkBMC)