Showing posts with label xmldap. Show all posts
Showing posts with label xmldap. Show all posts

Thursday, July 01, 2010

Information Cards in JSON

I added some code to xmldap to serialize Information Cards to JSON.
The rationale is that XML and especially XML Signature are a mess on mobile devices. J2ME is java1.3 and thus from the stoneage. But Android (java 6) is not better because javax.xml.transform is missing. Arghh!

- I am throwing away namespaces
- No deaply nested XML structures.
- No signature (yet?)!

I would like to standardize this or something similar.

This is a Britisch Columbia Card from the RSA interop in JSON:


{
"CardId": "urn:GUID:6d6693c1-6b1a-df11-b009-00143851d232",
"IssuerName": "stsip.systestv2.bceid.ca",
"MimeType": "image/jpeg",
"lang": "en-us",
"TokenServiceList": [
{
"UserCredential": {
"Type": "UserNamePasswordAuthenticate",
"Username": "SBCEID\\pwiebe10i"
},
"Address": "https://stsip.systestv2.bceid.ca/adfs/services/trust/mex"
},
{
"UserCredential": {
"Type": "UserNamePasswordAuthenticate",
"Username": "SBCEID\\pwiebe10i"
},
"Address": "https://stsip.systestv2.bceid.ca/adfs/services/trust/mex"
}
],
"SupportedTokenTypeList": ["http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"],
"Issuer": "http://stsip.systestv2.bceid.ca/adfs/services/trust",
"CardVersion": 4,
"SupportedClaimTypeList": [
{
"Description": "Level of Assurance achieved according to the rules of the ICAM IMI 1.0 profile located at http://www.idmanagement.gov/",
"Uri": "http://idmanagement.gov/icam/2009/09/imi_1.0_profile#assurancelevel1",
"DisplayTag": "ICAM Assurance Level 1"
},
{
"Uri": "http://www.cio.gov.bc.ca/standards/claims/2009/11/useridentifier",
"DisplayTag": "User Identifier"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/06/userdisplayname",
"DisplayTag": "User Display Name"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/identityassurancelevel",
"DisplayTag": "Identity Assurance Level"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/authoritativepartyidentifier",
"DisplayTag": "AP Identifier"
},
{
"Uri": "http://www.ocio.gov.bc.ca/standards/claims/2009/09/authoritativepartyname",
"DisplayTag": "AP Name"
},
{
"Uri": "http://www.cio.gov.bc.ca/standards/claims/2009/09/identityassurancelevel1",
"DisplayTag": "Identity Assurance Level 1"
},
{
"Description": "The e-mail address of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"DisplayTag": "E-Mail Address"
},
{
"Description": "The given name of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
"DisplayTag": "Given Name"
},
{
"Description": "The unique name of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"DisplayTag": "Name"
},
{
"Description": "The user principal name (UPN) of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
"DisplayTag": "UPN"
},
{
"Description": "The surname of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
"DisplayTag": "Surname"
},
{
"Description": "The private identifier of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier",
"DisplayTag": "PPID"
},
{
"Description": "The SAML name identifier of the user",
"Uri": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
"DisplayTag": "Name ID"
},
{
"Description": "Used to display the time and date that the user was authenticated",
"Uri": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant",
"DisplayTag": "Authentication time stamp"
},
{
"Description": "The method used to authenticate the user",
"Uri": "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
"DisplayTag": "Authentication method"
}
],
"CardName": "BCeID Information Card",
"TimeIssued": "2010-04-15T17:52:07.341Z",
"RequireAppliesTo": false,
"CardType": "urn:GUID:6d6693c1-6b1a-df11-b009-00143851d232",
"CardImage": "/9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABQAHgDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD340ZNBrg/FXxAGi301lbwGR4xhmCbhn9Py9qyrVoUo80jCviKdCPNUZr6l470TSbyO3u7pU3MFLZ+7k8Ej05/LtXS5NfJevXkuu+IYYVLLNczqiBjlRuIA+vNfV0TCOOOKSRTKFAPbJx6V6eNo0aMKc6cr8yv+VgoVXVTfQmzzS00dadXCbhRRRQAUUUUAFFFFABRRRQAUUUUAIa8M+KETWfiK6dJAY5grt3KsVHavUPGt5qNpoyf2asxkklCO0Kksq4PTHI7c15Le6ZqF4GMunXjseu6Fjn615ePqybVJU2+t+x4ebVZyaoxpuWzvY4a9037T5FyksiyqAYmVsFT1GD14Ne0atf3cNtAoupWEYWNsvlnKjBJPUnIJz6159ZeBL3U9UWNoZtPjQeYZ5YyNuCMbR3OSK7PUtGkWKNGv5ZCjeY5cAGRvUgdMnsK4uIs0hiaVCglyOG617K35M+m4YgneVSLW1rnqWmztc6ZaTuctJErMfUkc1brmvB+sRX1gLHyWims0VSC24MPUH+ldLXt4erGrSjOLumZ4ilKlVlCSsFFFFbGIUUUUAFFFFABRRRQAUUUUAIaMGlooAq3lhbX8apdRCRVOQCSMH8Konwvox62EZ/4E3+NTeIbuaw8NareW7BZ7ezlljYjOGVCQcH3Fckb3xJD4Eh8SQ6yJ5ltRdS29xbx+WwxkgFQCOPc0KipatIOdx2OxsNHsNMd3s7WOFnGGK55FXq5mbxlaWfgm38R3cbIs0SssCn5mdhwo/H9OaksbLXtStkutT1J7F5BuFpZon7oHszsCSfXGBTUOVdhOV2dFRXO2tvruneI4YpdQkv9JnifJliUPDIMEZZQMgjNblzdQ2kXmTyBF6c9z7UpNRV2xq7JqKy21RLiYWQFxazTITHIVXI9wDn9RXO+DtR1nVNc1uG/1RpYNNujBHGsMa+YPm5Yhc+nTFKnKNRNxewSTi0mdtRXBrea9cfEW60D+3JIrOO0F0rJbRb+SBtyVIxyea1NUj8T6Rave2F/HqixDc9rcwqjuo67WQAZ+orTk1tcnmOoorJ8N+ILTxNo0WpWmVVsq8bdY3HVTWtUtNOzKTuFFFFIAooooAxPGL+X4K1w4zmxmH5oR/WuQt/Dmr6x8OdNjttZYobSN/sckSiOUAZCFlw2O3Wu18S6dc6v4cv9OtHiSa5iMQaXO0A8Hp7ZrH0nSvFGm+HYNIE+lqYYvKW6BdmA6A7MAEj61rCVo/MiSuzgte8QLrnhPwvqL2q21raamsN1Cg+RCoGMe23P8q9pBBAIOQa5uy8EaVbeEW8OzK09vJlpZG4ZnPO/2PTH0pmlaf4k0G3SxSa01SziG2F53aGZV7AkBg2PXinNxkrLoKKa3OnZgqkngCuXtGutY1GW+SONo4iUh8xvlT3wOpqePTdZ1DWYrzVJbaG0gRxFaWzM5LsNu5mIGcAnAA707TtM1XTlkt4prfyWbIdgSw/CvMxcJOcFq49bdzqoySjJ9S/aaUIrs3lxKZ7kjAYjAUegFct4B/5GHxh/2Ej/AFrshHNBZlIWE0wBKmZiAze5AOB9BXMeFvD2taJrGq3V3JYSw6lcGdxE7hozzwMrz1HpXZQhGFNpaXMZtykmVLT/AJLVf/8AYJX/ANDWu5JAUk8Ada4dvDviaPxvJ4kgfS/ngFu1s0kmCnB+9t65HpWvf2Gv6zbNZz3Fpp1tKNsrWrNLKynqAzBQufXBraVnbUhXVznPhKh+x67PGCLSXUHMPoQPT9K9FqnpemWmjabDYWMQit4Vwqj+Z9SauVE5c0myoqysFFFFSMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD//Z"
}


Minor nit: lang="en-us". Might be better to use "en-ca"?

Tuesday, June 02, 2009

IE8, XHTML and xmldap.org

Some time ago I changed the HTML code that the xmldap.org site produces to XHTML.
It seems that IE8 is not happy with it, although I tested all pages with http://validator.w3.org/
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; InfoPath.1; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Sad. When I use IE8 and Cardspace to present an Information Card then IE8 offers to store a file to my local disk... When I post that file's content to the validator it verifies that this is valid XHTML 1.0 strict. And the content-type is "application/xhtml+xml". Maybe this is the problem?

Don't know whether I should care... Google does not consider IE8 to be a suitable browser (taken from here). Firefox is my browser and I assume that the others implement xhtml correctly too.
Anyways, if one IE-enthusiast offers a solution that is standard conform then I am happy to improve the xmldap site.

Monday, April 06, 2009

xmldap.org is down

I am sorry that xmldap.org is down.

Nulli Secundus, the former employer of Pamela Dingle, hosted xmldap.org until now. A big thank you for that.

Chuck and I have not found an alternative until now.
But I am an ethernal optimist too ;-)

Friday, October 24, 2008

XMLDAP XRDS

The XMLDAP relying party is now updated to provide XRDS data.

Notice the Information Card icon in the lower right corner in the status-bar of the browser.

You can start the card selector either through the sidebar - by dragging a card to the main window - or by clicking the Information Card icon. You need the latest version of the openinfocard id selector.

You may be wondering what the difference between the next and the previous image is?
I created a second card and used it at the xmldap relying party too.
The new claims were added to the previous set of claims. The claim "locality == Berlin" is new.

This image shows that the claim set was cleared. The relyingparty party has forgotten the privacy data after the "Clear privacy data" button was pressed.

THIS IS THE USER EXPERIENCE YOU WANT. DEATH TO USERNAME/PASSWORD.
(learn more)

Monday, September 22, 2008

Drop into a Site

I just uploaded a new verion of the XMLDAP RP source code and a new version of the openinfocard card selector.

You still have to compile you own version of the XMLDAP relyingparty because the current server still lacks a valid cert.
Signature validation of an newly imported card seems to fail too everytime. Sorry. Working on that (too).

Now for the new stuff. You can now display a list of your Firefox Identity Selector's cards in the browsers sidebar by pressing Ctrl-Shift-I. When you then drag a card onto the Information Card Icon the identity selector gets started and you can select a card to generate a token for the relyingparty. Cool.

It would be even cooler if the dragged card was preselected but for this I have to change the interface between browser add-on and identity selector.
The current interface for the getBrowserToken function is:

    GetBrowserToken: function (
issuer , recipientURL, requiredClaims, optionalClaims , tokenType,
privacyPolicy, privacyPolicyVersion, serverCert, issuerPolicy);


I will just add the new parameter cardid to this call. And while I am at it I will introduce a new parameter sslMode. "sslMode" tells the selector whether the browser thinks that the serverCert is an extended validation certificate or not. Adding more and more parameters to the call does not seem optimal but the xpt interface in mozilla code only allows simple and some more types. I can not define structs/records etc. Theses changes to the API affect the other Firefox extension too. I have to change CardSpace for Firefox too. And maybe others will make use of this API too? (Another subproject I don't have time for: convert the DigitalMe/Bandit/Higgins-Firefox selectors into components that use this API. Or another API we might agree on in the "Browser Integration Working Group" in the Information Card Foundation.)


Drag a card onto the relyingparty's icon.


How does it work: Well, I had to make another change and add a new parameter to the HTML object of type application/x-informationcard.

<form method='post' action='./infocard' id='infocard' enctype='application/x-www-form-urlencoded'>
<img id="icDropTarget" class="droparea" src="./img/card_off.png" alt=""
onmouseover="this.src='./img/card_on.png';"
onmouseout="this.src='./img/card_off.png';"
onclick='var pf = document.getElementById("infocard"); pf.submit();'/>


<object type="application/x-informationcard" name="xmlToken">
<param name="privacyUrl" value="https://w4de3esy0069028.gdc-bln01.t-systems.com:8443/relyingparty/?privacy.txt"/>
<param name="requiredClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>
<param name="optionalClaims" value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"/>
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"/>
<param name="privacyVersion" value="1"/>
<param name="icDropTargetId" value="icDropTarget"/>
</object>
</form>


The new parameter "icDropTargetId" signifies the element where information cards can be dropped onto. The img element in this example has this id. If the element is inside a form than it is submitted by the dropped information card. Simple!

Enjoy. (with Firefox 2 please)

Monday, September 15, 2008

xmldap STS update

While the service at https://xmldap.org/sts/ currently has an outdated certificate (Sorry!) the code did improve nevertheless.
When you compile and install the code on your server then you can now create managed cards that have the RequireStrongRecipientIdentity and RequireAppliesTo elements set.

I will update the applications on xmldap.org after we have the valid cert again.
The openinfocard id selector was updated too to read and interpret the new element in managed cards.
Enjoy.

Friday, August 22, 2008

xmldap / openinfocard new version


The openinfocard id selector now validates the signature of an imported information card and checks the validity dates of the signing certificate. The certificate chain and revocation lists are NOT checked. This is one feature that blocks an 1.0 release ;-)

Please make sure that you always use the latest version of the xmldap.jar (if you have an RP or STS that needs it) and xmldap.xpi (the id selector). In April I committed a version of the RP (xmldap.jar) to the svn repository that did not work with DigitalMe. I apologize for that.

Tuesday, August 19, 2008

xmldap.org is down

xmldap.org has lost its hosting. The startup that provided the space etc shut down and there is currently no replacement. Sorry.

Thursday, June 05, 2008

Doppelgänger



Today I updated the xmldap relyingparty to contain two HTML objects of type "application/x-informationcard". To keep things simple I just have put two forms on the website each containing one object. The only difference between the two is that on requires a self-issued card while the other does not restrict the issuer.

The id selectors seem to handle this well. I tested it with the openinfocard id selector and with CardSpace.

What is this good for?! Well, one object could request a card from the issuer "Mastercard" while the other requests a card from the issuer "Visa". Or one could request an issuerpolicy while the other does not...

Interestingly CardSpace fails the test on Pamela's test page for the OSIS interop test. It seems that CardSpace does not like the missing "requiredclaims" parameter...
The openinfocard id selector has its flaws too but they don't stop this test from "working" or do they?

Tuesday, June 03, 2008

OSIS I3 Information Card RelyingParty Feature Test


The sad truth is that nobody really cared to fill out the feature test tables for relyingparties during the OSIS I3 interop. This table shows only relyingparties that have at least one test result other than "Not Tested". The xmldap RP and all Microsoft RPs were deleted from the table for this reason. Even features that most RPs support have no utilizable value. The last two rows of the table should show "Works" for probably all RPs but they show the dreaded "Not Tested"...

This table is not usefull to conclude the maturity of the Identity Metasystem from it. Shame on us. Shame on me.

Monday, April 21, 2008

OSIS Interop Showcase at EIC2008


Wednesday and Thursday are the days to be in Munich to attend the 2nd European Identity Conference. Kuppinger and Cole were so kind to provide space and a WLAN and time and marketing people for the first post RSA interop. We will demonstrate interoperability during the last two hours of the expo opening time each day. Most of the RSA interop sites are up and working. The results of this interop go into the main RSA results table.

Tomorrow (Tuesday) is the day of interesting pre-conference workshops. I will attend the workshop "VRM 2008 - Unconference on Vendor Relationship Management" unorganized by Doc Searls. My colleague from T-Home, Michael Gärtner will present at the Liberty Alliance Standards Workshop. My colleague, Jörg Heuer, will participate in this panel discussion.

Tuesday, April 08, 2008

RSA WLAN slooow. or: bearer vs. holder-of-key

Trying to commit a change to the xmldap STS that makes it obey the subject confirmation method element in the RST.
BUT:

$ ping openinfocard.googlecode.com
Ping googlecode.l.google.com [64.233.187.82] mit 32 Bytes Daten:
Antwort von 64.233.187.82: Bytes=32 Zeit=348ms TTL=241
Antwort von 64.233.187.82: Bytes=32 Zeit=2787ms TTL=241
Antwort von 64.233.187.82: Bytes=32 Zeit=1318ms TTL=241


Ahhh. The fourth try to commit the files succeeded.

Please find the new version in the xmldap source code repository at the openinfocard project site.

Monday, April 07, 2008

OSIS Interop Media Alert

Shamelessly copied from Johannes Ernst's blog.


FOR IMMEDIATE RELEASE

April 7, 2008

MEDIA ALERT
Showcasing How Users Can Control their Identity Online, Industry's Largest Identity Interoperability Demonstration Scheduled for RSA 2008
Fifty-seven member open source identity group to test and demonstrate interoperability between user-centric identity protocols and providers

SAN FRANCISCO (RSA Conference 2008) - April 7, 2008 - Open Source Identity Systems (OSIS) will conduct the largest user-centric identity interoperability test and demonstration at the 2008 RSA Conference, April 7-11 at the Moscone Center in San Francisco. The 33 member organizations and 24 projects of OSIS will showcase network interoperability between identity providers, card selectors, browsers and Web sites, demonstrating practical uses for user-centric identity technology, including how users can "click-in" to Web sites via self-issued and managed Information Cards and OpenIDs. The user-centric identity model gives consumers greater control and security over their identity information, allowing them to determine how sensitive identity information should be shared at each visited Web site.

During the demonstration, OSIS members will illustrate interoperability between Information Card and OpenID software, the technologies behind user-centric identity.Features being demonstrated include:

* Enabling people to control what identity information is disclosed about them
* Portability of digital identities across software and platforms
* Management and use of Information Cards and OpenIDs
* Information Cards used with OpenIDs to enable phishing-resistant sign-in to Web sites

WHO:OSIS, a working group of Identity Commons (please see below for a list of companies and projects). Members of the group are committed to a goal of Internet identity interoperability across projects, protocols, companies and platforms.

WHAT:OSIS User-Centric Identity Interoperability Demonstration at RSA 2008

WHERE: RSA Conference, Moscone Center South, San Francisco, Mezzanine Level, Purple Room 220

WHEN:Tuesday, April 8 and Wednesday, April 9; public working sessions 11 am to 4 pm, demonstrations 4 pm to 6 pm
About OSIS

Open Source Identity Systems, a working group of Identity Commons, brings together many identity-related open-source and commercial projects, and synchronizes and harmonizes the construction of an interoperable identity layer for the Internet from open-source parts and software that interoperates with them. For more information on OSIS, visit http://wiki.idcommons.net/index.php/OsisCharter.
OSIS participating companies:

* AOL
* ATE Software
* CA
* Cordance
* Fraunhofer FOKUS
* FuGen Solutions
* Fun Communications
* Google
* IBM
* JanRain
* LinkSafe
* Microsoft
* NetMesh
* Novell
* Nulli Secundus
* ooTao
* Oracle
* Orange
* Parity
* Ping Identity
* Plaxo
* Siemens
* SixApart
* Sun Microsystems
* Sxip Identity
* Thinktecture
* ThoughtWorks
* TrustBearer Labs
* VeriSign
* Vidoop
* WSO2
* Yahoo!
* Zend

Projects and Organizations:

* Bandit Project
* Codeplex
* DiSO Project
* Dominck Baier
* Drupal
* Francis Shanahan
* Higgins Project
* I-names
* Identity Commons
* Information Cards
* LID
* OpenID
* OpenInfocard
* OpenSSO
* Open XRI
* Pamela Project
* Rob Richards
* Sharp STS
* SignOn.com
* SourceID
* Shibboleth
* Verisign Personal Identity Provider
* Xmldap
* Yadis

All company/project names and service marks may be trademarks or registered trademarks of their respective companies/organizations.
OSIS Participants Contact Information:

http://osis.idcommons.net/wiki/Category:Participant
Media Contact:

Charlotte Betterley

Novell

(781) 464-8253

cbetterley@novell.com

Monday, March 31, 2008

Interflop


You might have noticed that sometimes the security token on xmldap's relyingparty is not valid. The conditions on the token are not met because the time on the server was about 30 minutes off.
Chuck corrected this immediately and I wanted to verify that the relyingparty there now accepts a security token produced by the latest openinfocard id selector. I quickly installed it, but booom; it failed.
The line of code in question was unnecessary anyway so I cleaned up the javascript quickly; transferred the code from my lab machine to my office machine. Now the installation of the xpi went through but this time the token produced was "undefined". Strange. I did tests this on my lab machine yesterday; so what is the difference between the two machines?

Well, it turns out that the office machine had version 1.0.6 of the CardSpace for Firefox extension. After updating it to the current version 1.0.9 everything now works fine. ... Well, the certificate on xmldap.org expired two days ago. Argh, will be fixed soon. Sorry.

That was a nice 5 Minute adrenalin shock.

Friday, March 28, 2008

Dynamic objects

Last autumn when a change in Firefox forced us to change the HTML object tag handling we kicked XBL and used DOM event handlers as the primary mechanism to detect and handle objects of type application/x-informationcard.

At that time the three id selectors that use this same piece of code openinfocard, CardSpace for Firefox (on codeplex) and DigitalME stopped working on sites that dynamically create or change the objects of this type.

Yesterday Barry from the SharpSTS project contacted me that his site does not work with "my" extensions... Well, at first I was reluctant to put too much work into supporting this javascript kungfu but Mike Jones persuaded me.
As it turn out it was not that much work as I expected.

Please download the new version from the codeplex site here.
A new version of the openinfocard id selector will be available soon too.

Here are some sites that now work again with the Firefox extensions:

FriendsWithCards


SharpSTS


Kim's Identityblog


These interop tests were done with Firefox 2.0.0.13 and CardSpace (.NET3.5).

Friday, February 29, 2008

opensso RP with xmldap code


Superpat posted here that there is now a new opensso extension that enables opensso to be an information card relying party.
Patrick Petit (pictured) who wrote this extension uses the xmldap library to process the xmltoken. Great. Note to self: be carefull when changing the xmldap codebase. Don't break this opensso extension.
Another (simpler) SUN access manager login module is described here. I am glad that Patrick improved my demo-grade login module to opensso quality. Thank you.

Tuesday, February 12, 2008

Brown Bag

Today I tested the openinfocard id selector and the xmldap sts against the python relying party.
At first I got the dreaded "does not contain a InclusiveNamespaces element" error/info but this was easily fixed.

Here is a screenshot after I presented a token from a managed card issued by the xmldap STS (a local version; I will upload it soon to xmldap.org) to the python RP:


Here is a screenshot after I presented a token from a self-issued card to the python RP:


While looking at the python code I noticed that it checks whether the InclusiveNamespaces element is present but it does not test whether the PrefixList makes sense. Could somebody please write more about the brown bag attack, how a meaningful security token with InclusiveNamespaces looks like and describe how an attacker might exploit a missing InclusiveNamespaces element in a information card scenario? My guess is that this is more of a theoretical attack because if all connections are protected by SSL than either id selector or STS must be compromised. I guess that you have more troubles than forged signatures when either case it true.

Friday, February 08, 2008

xmldap relyingparty and glassfish

Here is a description on how to use the xmldap relyingparty with SUN's glassfish application server. It works like a charm.

1) Download GlassFish

http://www.java.net/download/javaee5/v2ur1/promoted/SunOS/glassfish-installer-v2ur1-b09d-sunos-ml.jar

2) Run the installer/unpacker
java -Xmx256m -jar glassfish-installer-v2ur1-b09d-windows-ml.jar

3)
cd glassfish 
lib\ant\bin\ant -f setup.xml

4) Add D:\Programme\glassfish\bin to the PATH variable
echo %PATH%

OK
5) Started glassfish
asadmin start-domain domain1

Verified this by using Firefox on
https://w4de3esy0069028.gdc-bln01.t-systems.com:8181/



6) stop glassfish
asadmin stop-domain domain1

7) edit websrc/xmldap_rp/WEB-INF/rp.properties
keystore=D:\\Programme\\glassfish\\domains\\domain1\\config\\keystore.jks
keystore-password=changeit
key=s1as
key-password=changeit
privacyStatement.text/plain=/WEB-INF/privacy.txt
privacyStatement.text/html=/WEB-INF/privacy.html
privacyStatement.text/pdf=/WEB-INF/privacy.pdf
requiredClaims=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddressoptionalClaims=http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress ttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country ttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender

8)
cd openinfocard/ant; ant; 

9)
cp ../build/xmldap.org/relyingparty.war cygdrive/d/Programme/glassfish/domains/domain1/autodeploy/

10) Start glassfish again
asadmin start-domain domain1

11) Use Firefox to open
https://w4de3esy0069028.gdc-bln01.t-systems.com:8181/relyingparty/


looks like the xmldap relyingparty. Fine.
12) login using dottie's information card
The openinfocard id selector version is 0.9.9.20080118



Valid Signature: true
Valid Conditions: true
Confirmation method: urn:oasis:names:tc:SAML:1.0:cm:bearer
Audience is restricted to: https://w4de3esy0069028.gdc-bln01.t-systems.com:8181/relyingparty/
No Certificate in Token
You provided the following claims:

givenname: Dorothy Mae

surname: Murphy Mortimore

privatepersonalidentifier: TFJmTjJIUlVyNG8yTGR3NmQySHp1Y3JOU0VHYit5NXErTDNZQkdRZk40ST0=
Your user agent is

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11


The java verion is jdk1.6.0_04.
Enjoy.

Friday, January 11, 2008

xmldap code used in opensso

Gerry Beuchelt blogged about a deep-dive event the opensso team is having on the Microsoft campus. He sent an email to Chuck that some of the code used in opensso is from the openinfocard project. That's cool. Additionally they found a wrong namespace used in X509 authentication. A part of the code that is currently not used in the xmldap IdP. I corrected this and added a JUNIT test for this authentication method. Hopefully we will be able to accept X509 and other authentication methods in the xmldap IdP soon too.
Actually a year ago Chuck and I were thinking of integrating our code into opensso and continue to work there on the code. I wrote a LoginModule for Sun's Access Manager and sent it to Chuck to forward it to the opensso team which Chuck knows from his time at Sun.