Wednesday, November 21, 2007



There. I did it. Now please make it happen, Apple.

Lots of progress, little updating

A lot has happened since the last time I've posted:

  • I've got SAML 1.1 working with LifeRay Portal. This was for a demo, but the code could be used in production (IMO). It works in the same way that the existing CAS filter works, except that there's a lot more code responsible for validating SAML.
  • Been poking around with the OpenSSO Federation Libraries. I'm trying to find a SAML 2 implementation that I can use (quickly), and the OpenFedLib libraries seem a bit more intuitive than the upcoming OpenSAML2 implementation. (Probably because I haven't taken the time to figure out their XMLTooling) I've got SAML2 tokens shoved into the InfoCard IDP, too bad there are exactly 0 RPs that'll support it. :)
I'm really excited about the Claims-based architecture stuff that Kim's been talking about. We're been looking at such an approach for assertion translation/normalization. More on this later.

Monday, August 20, 2007

Why can't the DoD learn from others' mistakes?

Joint Enterprise Directory Service (JEDS)

Although there has been failure after failure when attempting global aggregation of information (for countless reasons), why is it that we're spending more money going down this dead-end trail? Has the case for federation not been made yet? The litany of technical and security concerns which go painfully unanswered is saddening.

Tuesday, June 19, 2007

HSPD-12 and Privacy

Stefan offers some interesting points regarding the debated anonymous credentials, a term which Kim as sworn off:

Whenever you read about “anonymous credentials”, you should really think of these as minimal disclosure certificates. “Minimal disclosure” implies three privacy properties: (1) minimization of traceability, (2) minimization of linkability, and (3) selective disclosure:
  • Minimization of traceability means that there is nothing in a certificate beyond any disclosed attribute data it may contain that can be used to link its presentation to its issuance.
  • Minimization of linkabilility means that there is nothing in a certificate beyond any disclosed attribute data it may contain that can be used to link its presentation to the presentation of other certificates of the same user.
  • Selective disclosure means that the user of a certificate, when presenting the certificate, can (unconditionally) hide attribute data contained in the certificate that does not need to be revealed. More generally, properties of encoded attribute values can be disclosed while any other information remains hidden.

These properties hold in the face of collusions between relying parties and identity providers. What’s more, they hold unconditionally, even if relying parties and identity providers actively collude from the outset and try to build in “cryptographic backdoors” in the algorithms used to digitally sign identity claims.

This has interesting implications with HSPD-12, the requirement for all Government activities to use strong authentication for networked systems. This has been implemented by issuing smart cards with an embedded PKI certificate to government employees (and contractors) and requiring the use mutual SSL pretty much everywhere. So rationale behind the client PKI certificates aside, we can say that linkability and traceability are foregone conclusions in these environments. There is, however, a battle to be had regarding discretionary user information release.

Identity federation in such situations are less of an issue of federated authentication, but more focused upon the federation of attributes to enable authZ decisions.

Cardspace Quirks

I'm glad to see that I'm not the only one out there battling various Cardspace bugs and quirks. I'm shocked that I hadn't see her blog earlier.

As the shepherd of the Pamelaware module, maybe she can focus a bit of effort in quashing the bugs in that code which were inherited from Kim's implementation.

Privacy and Need-to-know

It's rather frustrating to see how many people dismiss the concept of discretionary information release as an issue which only the tin-foil-hat and "naughty" communities are concerned. Perhaps I have too narrow a view since I tend to look at things from an enterprise/government point of view, but we're not just dealing with the commercial space, are we?

I spend a great deal of my day (everyday) trying to explain the need for such concepts within the DoD. An intrinsically hierarchical group where every agency assumes they may have carte blanche access to peer and subordinate agencies, there is little true federation. To share data, it normally requires one organization or another to surrender control over their information, leading to power struggles of epic proportions.

When you finally get them to sit down at the table, the concept of cooperative data exchange (rather than the forced or ransacked types) are usually foreign concepts. If not, they are typically jaded because of similar over-promises in the past which ultimately led to the above situation. Eyes cut at one another suspiciously. When they finally acquiesce (due to political or financial pressure) they instinctively demand to release as little data as possible. A desire to know and retain oversight over the data is being "surrendered" about their users when they use external resources, and to have a clear audit/accountability trail for external users who access their resource is quite common.

Note that exact same things are usually demanded when most people talk about privacy, except the here we call it "need-to-know". Need-to-know used to simply apply to release of well-defined and labeled information; within the enterprise, however, this concept has reached a new level. All information is regarded as sensitive until deemed otherwise. Sometimes it's because they have legitimate security concerns, other times it just because of stubbornness.

So the issue that the Government (with a capital "G" this time) is often cited for shortfalls, cross-organization information sharing, is unfortunately tied to this problem in my opinion.

Sunday, June 17, 2007

Firstrade Privacy Shenanigans

I've been with Firstrade for some time now, allowing me to invest what little extra money I occasionally find. When initially establishing the account, I faxed my life away to them (voided check, form filled with personal information, etc). I've expressed my frustration with the number of paper documents they use, littered with personal information, so I was happy when they offered an online version of the information. My shredder finally got a reprieve.

Recently, however, I changed the institution with which I bank and attempted to notify Firstrade of the same. As directed on their website, I sent the updated forms via fax to them. A day later I received a notice via email stating that I needed to take the forms, a voided check, and two forms of ID and mail the information to them. Having lost a passport in the mail recently, I was not happy with the idea of putting every piece of personal and financial information into one envelope handled by the USPS.

So I inquired as to the rationale behind this demand. After all, my experience with a passport would support an argument that fax is more secure than postal mail. If their concern was regarding the reputability of facsimile documents, I believe that there is ample legal precedent to prove that such requirements are unnecessary. This was the response:

Thank you for emailing Firstrade. Please note that currently Firstrade requires that amended ACH setup requires you to send in the actual form with the voided check. This is a risk management issue that we are working out with ADP Clearing. We apologize for any inconvenience.

"Risk management". Why did that sound familiar? I deal quite a bit with management throwing the term around, so I know how it can be abused. Does the term actual have any valuable meaning in the above statement? It did not to me. It appeared as if they wanted to throw in a obtuse term which will intimidate the average customer to simply accept the assertion. I'm a bit more stubborn than that, unfortunately.

The only conclusion I could draw was that, due to some dispute between them and ADP, they are placing the burden of the "risk" upon the customer. I wasn't too happy with that:

I don't believe I fully understand:

To cover your "risk-management" concerns, you're putting my personal information at risk by forcing me to send it through the mail? I'm going to put ID cards, a check, and account information into one envelope handled by the USPS? Your risk management is, then, to shift all of the risk onto your customers?

Not going to happen.

Not that I expected to get a concession in response to the email, but I was hoping for at least a more coherent explanation of the "risk" they were trying to manage. Instead, I got an equally cavalier and patronizing email in response:

We are writing in response to your inquiry regarding the ACH profile amendment for your account ***. Kindly note that we are unable to process the amendment at this time, due to the fact that the required documents are not yet received. We understand your concerns about your privacy; however, risk management measures are necessary.

Damn. And I thought that the only place I had to worry about wanton abuse of security terms was while at work.

Friday, June 15, 2007

Interop (OpenSaml and PHP Infocard)

What I've had to do so far to get the PHP RP to accept an OpenSAML-created assertion:

1) Force namespace prefixes for all SAML elements. The default xmlns values are eventually processed by the PHP code, though are pushed to the end of the element (breaking c14n)
2) Turn off the inclusive namespace prefix directives
3) Disable all unused namespace declarations. Saml, Samlp, xsd, xsi, and a few others are declared within OpenSAML objects (presumably for flexibility)
4) Change the xmlsec encoding of the certificate, which pretty-prints the base64 certificate with various unneeded (but not egregious) whitespace
5) ... Eh, I started blogging too late to catch everything. 1-4 are the major changes.

It finally works though. These are all bugs with the PHP code so far as I can tell. Why change the IDP code then? Because it's pretty clear from the few RPs out there that Kim's code has made an impact and is used in many projects. The RP accepts some SAML, and ultimately interoperability comes first.

Hopefully he'll take it under advisement for the next revision.

OpenSAML and Infocard

OpenSAML (to include Apache Xmlsec) and the PHP RP seem to disagree about what to do with unused namespaces during canonicalization. Xmlsec strips out the namespace declaration, whereas the PHP keeps it in. Looking at the spec, I'm going to side with Xmlsec.

Raw XML:

<attribute xsd="" xsi="" attributename="surname" attributenamespace=""><attributevalue>MyLastName</attributevalue></attribute>


<Attribute AttributeName="surname" AttributeNamespace=""><AttributeValue>MyLastName</AttributeValue></Attribute>


<Attribute xmlns:xsd="" xmlns:xsi="" AttributeName="surname" AttributeNamespace=""><AttributeValue>MyLastName</AttributeValue></Attribute>

Long time, no post...

Just throwing out notes before I forget.

Kim's PHP Infocard implementation appears to have a problem with its canonicalization routine. To demonstrate, let's look at this example assertion element:

<assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" assertionid="uuid-1B045A32-5024-B4EB-93AE-0D718C87BC0D" issueinstant="2007-06-15T22:35:05.993Z" issuer="https://xxx" majorversion="1" minorversion="1">...

Which, in this case, ends up being the spec compliant. The PHP code incorrectly forms:

<assertion assertionid="uuid-1B045A32-5024-B4EB-93AE-0D718C87BC0D" issueinstant="2007-06-15T22:35:05.993Z" issuer="https://xxx" majorversion="1" minorversion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion">

This places the namespace after the attributes, which violates the spec. There are a couple of other little quirks I'm hitting which I'll post as I find them.

Wednesday, February 21, 2007

OpenID and Unique IDs

George Fletcher, a really smart AOL guy, mentions in his latest entry:
One final thought. There should be no reason why my IdP can't provide public personal identifiers in certain instances, pseudonymous identifiers in others, and temporary identifiers with claims in still others.
I would agree that in the generic sense of an Identity Provider (IdP) that such an assertion holds. In some implementations, especially in OpenID's case, this obviously isn't true. This breaks when you depend on the user to serve a unique identifier directly to the verifying resource/service provider. Not to say that this couldn't be fixed in practice, mind you.

The discussion regarding reputation in his post is a valid one. I just happen to believe that it's more of a convenient "feature" that you can't turn off. There are a lot of situations where this is bad.

AOL's (Really)OpenID

Can someone please explain to me how this is going to foil a spammer's script?

Perhaps I'm just confused. I realize that it's just supposed to be a beta implementation, but it's going to be hard to sell OpenID even as a blog-spam panacea with these kinds of problems.

Also, could we offer some OpenID-relevant security tips instead of the mind-numbing password length/composition suggestions? How about verifying the use of https, an address, appropriate use, etc. This issue may lead into discussions regarding the level of exposure that the user has to the OpenID experience. How aware should the user be of the underlying technology? Some have suggested that such exposure be minimized; I would suggest the contrary in this case.

Tuesday, February 20, 2007

Digg and OpenID

Well, I knew it would eventually happen- a popular OpenID Digg article. I was curious, however, the form it would take. And now that Digg has thrown its support behind the initiative, the Web 2.0 community has taken notice. Here's the article I found:

Here are 5 reasons why I think OpenID Rocks:

1) 1 ring to rule them all - why wouldn’t you want the ability to have 1 sign-in across all blogs?

2) Bye-bye comment spam.

3) Verify who is actually making comments. Many fake Matt Cutts’, Jason Calacanis’ make comments and require verifying IPs or other time-consuming checks when prolific people do comment.

4) MyOpenID’s (inaptly-named) affiliate system is a nice tool for developers and large site owners.

5) De-centralized authentication leaves no single player holding all the cards.

Here are 6 reasons why OpenID sucks

1) It is (as yet) too complicated for average website owner to implement.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Now, there's a variety of misconceptions as well as informed points in this piece, but it represents the common perception of OpenID by a relatively "enlightened" Digg user. Similarly, the Digg comments always make for great reading. Here, a response to the above:
I'm getting sick of this FUD over OpenID. It has THE SAME "TRUST" AS EMAIL BASED AUTHENTICATION. The only differences are:

1. You can change your provider at any time but keep your same openID (a plus)
2. They can't send you anything (another plus).

YOU manage your authentication. They don't need to send you password resets etc. They don't have an email address to sell to a thrid party, or to spam you with their product "newsletters". OpenID is BETTER than email based account management.

The only true con is that you REQUIRE a website (1 page) to use one.

1) It is (as yet) too complicated for average website owner to implement.

Uh.. you paste a line of html into your index page.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

It's as secure as email as a login mechanism. If your webserver is compromised you lose. If you email server is compromised you lose. How is this any different?

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

Yes there is. You don't link to the fake Mark Cuban's provider in your page. It's as simple as that. What's to stop someone from making a fake email address claiming to be you?

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

This is called RTFM. Put "openid" into any search engine and there's your answer. If someone knows enough about OpenID to want one, they will be able to find out how to get one.

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

This has nothing to do with OpenID as a standard. Just the quality of the particular plugin you're looking at.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Your "security" on financial sites is only as secure as the email address you associate with it. Your online banking security is only as secure as your email account.

Just as with email, you can be your own provider. There is no requirement to EVER trust a third party.

The ONLY WAY to compromise an OpenID account is to either compromise the webserver hosting the link to the provider, or to compromise the provider. If your email server gets compromised its the SAME RESULT.
While I'm not going to sit here and detail the problems with both posts, it does represent the understanding and perception problem that OpenID currently has. I believe it only goes to further my assertion that OpenID is still not ready for the limelight. Digg's adoption of the standard is certainly a boon for the OpenID community, but it may lead to a new group of users which is blindly passionate about technology they do not fully understand. (See above)

I'm not posting this to disparage the Digg nor the OpenID communities, but I do believe that the OpenID guys owe it to their prospective users to discuss the pros and cons of the technology. (Some of which I described in my last post)

Friday, February 16, 2007

AOL OpenIDiocy

While the subject is intentionally inflammatory, I am simply frustrated how AOL can push a specification into the limelight which makes security worse in its current form. Unfortunately, the hype and ballyhoo which has ushered in the coming of OpenID has largely excluded any intelligent discussion of the security implications outside of the email lists. Now, I'm happy to hear about the integration and use non-phishable technologies with OpenID (such as Firefox 3.0 & CardSpace), though AOL's decision to move ahead without addressing the array of concerns is rather careless. Even if AOL's intention for the service is as a proof-of-concept or a demonstration, it exposes very real credentials and resources.

To reiterate the security concerns, here's why I won't use an AOL OpenID:

1) It places too much power in the hands of a potentially dangerous website. Instead of sending me to, I get sent to a similar looking site. In AOL's case, this is painfully easy to pull off given the simplicity of their interface. After naively providing my credentials to the site, all of my attached resources that I consider valuable are compromised. It puts any OpenID protected resource, my AIM account/email (if I used it), and any other resource where I might reuse the same credentials at risk. Now, I don't reuse passwords between resources, but how many people do?

2) It creates OpenID's for people who don't understand OpenID. I can now create a website that offers a login page that says,

Don't have an OpenID? You do if you have an AIM account! Log in right here:

and continue with my phishing attack. Now such an attack could admittedly happen even outside of the OpenID context, but it immediately taints the (otherwise) good work that has been done in the community. Even with a non-phishing OpenID site, does the average user realize that they're revealing their screen name to the site? Not a pseudonym/unique ID, but the actual user's screen name.

3) AOL's OpenID login interface does not have human-in-the-loop verification. How many AIM accounts are used by spammers currently? How trivial is it now for that account to be "repurposed" into a blog spamming account for those sites which support OpenID? OpenID's best defense so far to such threats has been the high-cost, low-return of setting up a spammer-sponsored OpenID provider. AOL's easily automatable interface, complete with innumerable already established dubious accounts, are quite likely to overcome this problem for them and form a blog-spamming haven.

Also, consider that the OpenID mantra has been operation in full promiscuous mode. When blogs start getting spammed, are they going to block all of AOL? Individual users?

4) The concept of having a unique ID on the internet just doesn't suit me, especially when it's my AOL ID. Now, many will say that this is "tin-foil-hat land", though I think this is just as bad, if not worse than, the Intel serial number controversy. Is it really that much worse that you have people actively offering the ID to sites rather than hardware doing it for them? At least the processor offered an obscure ID number with it rather than my AOL screen name!

And, if you think for a second that the fact that you consent to the transaction is any consolation, please refer to point #2 above.


There are further questions about the accountability between providers and websites, the ability to preform MITM attacks, and other privacy concerns, but the 4 reasons above should be enough to invoke some critical thinking. Some of these issues are with OpenID, while others are related to AOL's implementation, though all are arguably frightening.

I am not an opponent of OpenID. After the phishing problem is handled, I think that it will be a highly useful tool for authentication to low-value resources (i.e. most of the sites on the internet), especially when you understand the risks and implications. But it's just not ready for the prime-time yet. But with AOL's decision and the hype from the Web 2.0 crowd, it's already on its way there.

I would encourage anyone considering using this technology (either as a client or a implementer), to seriously research the security implications. Even more importantly, AOL should actively offer disclaimers regarding these issues. They're too important to allow a user to fall prey to a nefarious website.

Sunday, February 11, 2007


The latest version of the InfoCard integration guide calls out a problem that I groaned about earlier:

IMPORTANT NOTE: Notice that the URI used as the value of the ValueType attribute on the wsse:KeyIdentifier element to indicate a SHA1 thumbprint based key identifier is a slightly outdated URI value. The new prescribed value as per the WS-Security v1.1 standard should be as follows:

Support for this newer URI will be added in a future versions of the Information Card Profile.

So as much as I would like to think that someone out there actually listened to my complaints, I realized that this was probably documented before I said anything. Oh well.


Ah. Sweet success. Finally.

A InfoCard compliant STS which issues credentials from a LDAP backend based on X509 credentials. A pursuit which was wonderfully enlightening, painfully tedious, and maddening at times. Thanks to an idiotic obsession to complete this thing and some limited help received from a Java PingIdentity guy on the MSDN forums about proper certificate hashing (!), I've got a working proof of concept based on the work of the XMLDAP work.

As I close the compiler and take a few deep breaths (and back everything up to a DVD-R), I figured I'd have a quick reflection upon a few things I've learned.

1) Microsoft hasn't seemed to dedicate the necessary support to handle developers' questions. Perhaps it was just the time of the day/week/year that I asked, but getting the ear of anybody of consequence on the MSDN forums was not possible. Simple yes/no questions appear to languish unanswered for weeks and months. I won't rant about this subject again, but an identity metasystem built upon open standards but with a closed reference implementation and no support can be just as frustrating to develop for as an all-closed solution.

2) PingIdentity announcement of their intention open-source their InfoCard related code (RP and STS) is just lip-service. I defy them to prove me wrong. :)

3) The CardSpace client wants WS-Security headers, but it really doesn't care what's included.

4) The CardSpace client will fail with a critical fault if it cannot write to the logs. It's a bug that's been identified in the MSDN forums, but it's pretty damn frustrating when the CardSpace client fails, causing IE to fail, causing Explorer to fail, eventually requires Windows restart. (for approximately 20 iterations when I thought it was my STS cards causing the problem)

5) One's progress on a given task is directly proportional to the demand for one's presence elsewhere. It is, therefore, impossible to get anything done.

6) As I continue working with the technologies, the more my mind wonders regarding use cases and applicability.

More to come later, but a good high-level start.

Tuesday, February 6, 2007

CardSpace Apache Module

Ashish Jain announced the release of the Apache CardSpace Module today in his blog. I'm really happy to hear that. Together with the Firefox 3.0 adoption of the spec, there should be plenty of tools to start piecing together some really interesting solutions.

But where is the bigger fish (IMO), the open-source STS? There is apparently some interest judging from the comments on his blog, but emails requesting access have thus far been dismissed. Or maybe it's just my emails.

My IDP Quest...

I'm still having fun in my IDP quest. I've successfully navigated the X509V3Credential issue thanks to some help from the MSDN board and despite some apparently bad or outdated MS doco.

What does that mean? I'm accepting requested along with a client certificate (which I trust), which is then included into the card I issue. When the user selects the card, the CardSpace client will retrieve the certificate from the appropriate store and use it for authentication back to the IDP. The IDP will retrieve attributes based on the certificate subjectDN from an LDAP, and send them back to the user in a SAML assertion. And then it dies.

Why? I'm not including the right WS Security headers in the response, if the CardSpace logging is to be believed. Which ones do I need to include? Got me. I don't know if it's a requirement set by the CardSpace client or by WS-Trust (which I'm admittedly not terribly knowledgeable about), but I'm working on it now. I'm going to review the spec to hopefully find some insight on the problem.

Saturday, February 3, 2007


As a frequent listener of STODID, I have to say that I'm in complete agreement with Paul. Not that I'm not interested in OpenID, but let's diversify a bit...

I'm glad Aldo is listening, however. Maybe some specific discussions about these technologies in the enterprise realm (and no, not just OpenID).


(Not) Working with InfoCard

So I've got a working STS based on the work provided by the XMLDAP code- great work by the way. Issuing card and pulling user info from an LDAP, I'm really happy about how things are coming together.

Now if I can just get X509 authentication working. I've hit a few issues along the way, but the cards are kinda working now- they're at least importing correctly. I'm issuing cards with X509Credential identified with a SHA-1 hash of the certificate I want to use, but the Windows CardSpace client goes brain-dead when trying to find the certificate I specified. I browsed the MSDN forums looking for a solution, and I'm hoping that someone can clear up why this is happening.

I'm a bit frustrated at the problems I've been hitting; not because I because I have any expectation of a seamless development/integration process, but because I don't have the ability to examine the CardSpace client. As the de facto reference implementation for identity selectors, not supporting it is simply not an option (my personal admiration for the XMLDAP selector aside). Perhaps I've just been spoiled by the ability to load open source products into a debugger and figure out why things are breaking, but I hate being hamstrung by an issue that I could likely figure out with a bit more visibility.

Please, Microsoft- provide more context and detail on the client logging. A namespace error leading to an entry of "Inner Exception: 'None' is an invalid XmlNodeType. Line 1, position 1." isn't terribly helpful. I realize that this is a V1 release, but this is painful. When attempting to use the corrected card using X509, the client dies with a dialog box stating "The certificate associated with this card could not be found" and not so much as an log entry for an undoubtedly loggable event.