I used the holidays to reintegrate drag and drop into openinfocard.
After installing the openinfocard Firefox addon (xmldap-0.9.9.201012271501.xpi) and surfing to a relyingparty e.g. https://xmldap.org/relyingparty/ you can now open the Firefox sidebar (using Ctrl-Alt-Shift I).
The sidebar shows the list of Information Card you have.
You can now drag one card to the form that contains the object element. The object element is not visible but the drag and drop handler is registered to the object element and the enclosing form. In the case of the xmldap relyingparty you can drag a card to the image and the drop event will bubble up to the form.
Dragging an Information Card to the main page
Selector open with dragged card selected
xmldap relyingparty with claims from dragged card
Should I auto-submit the card because the dragging expresses the user consent already?
Monday, December 27, 2010
openinfocard drag and drop
Posted by Unknown at 12:13 PM 0 comments
Friday, November 05, 2010
Information Cards, WS-Trust and SAML and OAuth, oh my!
While reading Pat Patterson's blog post "WS-Trust and SAML and OAuth, oh my!" I noticed that this fits into the Information Card flow.
Pat describes Ping's Salesforce mobile flow:
- Mobile app accepts the username and password, and submits them to PingFederate in a WS-Trust request.
- PingFederate validates the user credentials, creates a SAML assertion and submits that to Salesforce.com in an OAuth 2.0 request.
- Salesforce.com validates the SAML assertion and responds to PingFederate with an OAuth access token.
- PingFederate in turn replies to the Android app with a WS-Trust response containing the access token.
- The Android app uses the access token to invoke the Salesforce.com REST API.
Now let's Information-Card-ify this:
- The user visits the mobile version of his company's application page at Salesforce. (No extra App just HTML5 and CSS3. Which is probably easier to implement than an App for Android and Blackberry and iPhone! The web app is available anyway.)
- The site offers to use Information Cards to authenticate and the user clicks the purple-i icon to do so.
This click requests the browser to follow a link with an icard-https scheme.
The browser/OS notices that this scheme is handled by Azigo's card selector for the iPhone. We, Deutsche Telekom Laboratories, have prototype selectors for iPhone and Android too.
As it happens the card store contains an Information Card issued by the company and this card is the default card for this site. The selector contacts the card issuer (PingFederate) like in the other flow using WS-Trust. - PingFederate validates the user credentials, creates a SAML assertion and submits that to Salesforce.com in an OAuth 2.0 request.
- Salesforce.com validates the SAML assertion and responds to PingFederate with a session token.
- PingFederate in turn replies to Azigo's selector with a WS-Trust response containing the session token.
- The selector tells the browser to post the session token the Salesforce application and the user is "in session".
So, what is different for the user and his company:
- No App for each mobile platform!
- The user's credentials are entered at the company site (implemented by PingFederate)!
- If the card were backed by a self-issued card or by a certificate then we even get rid of username/password!
Using oauth to obtain a session token may sound unusual but then oauth is token agnostic... Or Salesforce would provide the oauth token and that would then be used by the webapp to authenticate it's calls to Salesforce's REST API... Life's good.
Thoughts?
Learn more about Information Cards at the Information Card Foundation!
Posted by Unknown at 2:11 AM 1 comments
Labels: Information Cards, oauth, Salesforce, SAML, WS-Trust
blogger.com refuses to obey to HTTPS Everywhere
While starting to write a new blog post here at blogger.com I noticed that the site does not use SSL. As I have HTTPS Everywhere installed I added *.blogger.com and *.blogspot.com to the list of domains were I want to use SSL the whole time.
But... my browser is always redirected to http://www.blogger.com/.
This is not what I want...
Posted by Unknown at 1:54 AM 0 comments
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"?
Posted by Unknown at 4:28 PM 1 comments
Labels: information card, json, OASIS, xml, xmldap
Wednesday, June 09, 2010
Thursday, May 20, 2010
Application Secrets vs. Key Pairs
I was just reading about the new Google Storage API for US developers and I am wondering why we see application secrets so often?
Google is generating an application-id / "access key" and up to five application secrets for different projects a developer is working on. Fine. The developer has to sign each request to the storage API.
http://code.google.com/apis/storage/docs/getting-started.html#keys
I assume that Google might even generate code snippets for a given pair of access key and application secret to sign requests to make things really easy for the developer.
Does nobody fear that Google admins might misuse the developer credentials?
Does nobody fear that Google's database of developer credentials might be breached one day?
What is so hard in using key pairs for developers? I know that some people faint when you use the three letter word "RSA" or "DSA" or whatever smells like asymmetric crypto. But if I have to sign a request anyway then where is the difference between symmetric and asymmetric? Is performance really still an issue? gmail is now SSL which is good. So here security finally won.
Generating a keypair is really simple and using it to sign bytes is as simple as using a symmetric key. Yes you have to protect the private key but not more than you have to protect the symmetric key.
It is harder to autogenerate code snippets because the generator does not know the private key or how to access it. But is this the point?
With asymmetric crypto there is no database of keys that can be stolen because the private key is not on a central system. And the developer credentials can not abused by Google operators which is good for audits and Google's liability.
So why are symmetric keys so ubiquitous? They are nothing than passwords and share some of the problems passwords have.
Posted by Unknown at 3:04 AM 1 comments
Tuesday, May 18, 2010
oauth 2.0 scope is the new black
David's openid connect proposal uses oauth2.0 to get an access token to access the user's info API.
Openid connect does not define a new flow for oauth but uses a scope with value "openid" to signify that this kind of access token is requested.
What I am missing here is that there is no way for the client to specify which of the user's information it wants to access. The users might choose to release only a subset of their information at oauth-approval-time but they have no way to know what the client is requesting. I fear that the authorization server suggests to give away all user data and that the user will grant that access.
A quote from the openid connect proposal: "The (user info) server is free to add additional data to this response (such as Portable Contacts) so long as they do not change the reserved OpenID Connect keys."
This is the Facebook notion of privacy to give everything away by default.
I don't like that.
Even if the client does not want the data it now has access to it.
I am intentionally not suggesting a different proposal or new values for scope. But what I am thinking about here is probably obvious given the background I am coming from.
Posted by Unknown at 3:42 PM 1 comments
Labels: iiw, iiw2010a, Information Card Foundation, oauth, OpenId, openid connect, openinfocard
Monday, April 19, 2010
XAuth is Evil
Google and Meebo got it so wrong! Meebo with support by Google published a javascript xauth.js that tells a website which social networks the user is a member of. Information is stored on xauth.org and in local storage what my social networks are.
This is so wrong that it hurts. Sites should publish which social networks they support and the user should then choose which ONE they would like to use at THIS site at THIS time.
The xauth scheme just transports too much data to a central site too often.
Google should use its money and power to put this ability into the browser!
Start with Chrome and Mozilla (https://mozillalabs.com/conceptseries/identity/social-agent/). Yes, Google already supports Mozilla in this project but xauth is evil.
XAuth is not even acceptable as an intermediate "solution" before Identity in the browser is ready. Wrong, wrong, wrong.
I admit that website operators prefer it this way round and the collected data at the central server is definitely interesting and valuable. I think Google with good reason does not store that data on a Google server or do they? Who has access to that data? XAuth is not as bad as Microsoft Passport but not much better.
I fear that the user and privacy advocates are not strong enough to create "Identity in the browser"...
Don't do evil.
Posted by Unknown at 11:36 AM 1 comments
Labels: google, Google Chrome, mozilla, openinfocard, xauth
Thursday, April 15, 2010
SHA256 et al in openinfocard
I just added support for RSA-SHA256 etc to openinfocard's signature validation.
This came up during the RSA conference' OASIS IMI interop. The cards issued by ADFS2 are signed using RSA-SHA256. The team from the Government of British Columbia suggested to configure ADFS2 to use SHA1 for card signing but this way is better. Openinfocard is now more flexible in regard to signing algorithms. I added all DSA and RSA algorithms from http://www.w3.org/TR/2010/WD-xmlsec-algorithms-20100316/
Enjoy.
Posted by Unknown at 11:09 PM 4 comments
Labels: ADFS, IMI, OASIS, openinfocard, rsac, rsac2010US
Saturday, April 10, 2010
Comments-Policy
I will delete comments to blog posts on this blog written in a language that I can not read or understand.
I disabled comments on the last blog post because it seems to draw unwanted attraction.
Posted by Unknown at 7:34 AM 0 comments
Thursday, March 18, 2010
Identitymanagement and Sex
I learned something this morning. There is an ISO norm (ISO-5218:2004) that defines the representation of human sexes in IT systems "Codes for the
representation of human sexes". Probably there is an ISO norm for everything?
The actual representation looks similar to what is defined in the OASIS Identity Metasystem Interoperability standard.
0 - Not known
1 - Male
2 - Female
9 - Not applicable
IMI does not reference ISO-5218:2004 and "0 - Not known" is something different than "0 - unspecific". I guess the authors of the IMI spec do not know the ISO norm. Or is this due to the English differentiation of "sex" and "gender"? The ISO norm defines "sexes" and the IMI standard defines "Gender".
Interesting is the sheer number of "standards" to represent gender/sex.
http://de.wikipedia.org/wiki/Datenstandards_zur_Beschreibung_des_Geschlechts
(I have not found this in the English version of Wikipedia; Sorry.)
I find it interesting too that "transgender male" and "transgender female" do not exist in many standards. Although it may be inappropriate or even illegal to store the transgender information in a database but this is not the issue. Somebody might want to prove that he was formerly a she. It is better to have a representation in a norm/standard for all cases. The legal issues are outside the standard. ("legal" is always a path to headache for me e.g. http://de.wikipedia.org/wiki/Transsexuellengesetz)
OASIS should always check that new OASIS standards might be aligned to older existing standards.
I think the "gender" section of the IMI standard should be revised.
Thursday, February 25, 2010
Firefox Personas and openinfocard
If you have personalized your Firefox with Personas then your openinfocard selector window now shows the same background image.
Which is nice and a security feature too. A malicious website could try to create a window that looks like your favorite openinfocard selector but the website does not know how you personalized your browser. So if your card selector window does not show the same background image as your browser then something is phishy!
Get the current (xmldap-0.9.9.201002251149.xpi) version of openinfocard now!
Did I say that openinfocard runs on MacOS Snowleopard too?
Posted by Unknown at 1:52 PM 0 comments
Labels: firefox, openinfocard, personas, security, UI
Tuesday, February 23, 2010
Openinfocard openid login @ plaxo
When I referred to Mike's post about the Microsoft OpenID selector I was reminded to try this at the same site (Plaxo) as Mike. Here we go...
First I identified a small issue with openinfocard: The code matches the issuers now case-insensitive. Plaxo asks for "Yahoo.com" while my card says "me.yahoo.com".
So you need the latest version of openinfocard to try this "at home".
http://openinfocard.googlecode.com/files/xmldap-0.9.9.201002231732.xpi
Please install this into Firefox3 and browse to https://www.plaxo.com/signin?test.selector=1
Now click the "Sign in with OpenID" link to start the selector.
After selecting a card click "Send" to start openid discovery.
Yahoo! login and confirmation
Now I am logged in at Plaxo!
Nice!
Posted by Unknown at 5:40 PM 0 comments
openinfocard OpenID Selector
Last autumn Microsoft demoed an OpenID selector at the OpenID summit hosted by Yahoo.
Now - finally - I found some time to add this to openinfocard.
If you have Firefox3 and Java6u12 installed then you have everything you need for this. On a Mac you need Snow Leopard to have java6. Thanks to JohnB and Pam for trying openinfocard on a Mac.
Now install the openinfocard addon into Firefox by e.g. clicking on http://openinfocard.googlecode.com/files/xmldap-0.9.9.201002121109.xpi.
Browse to https://test-id.org/XP/Selector.aspx
Clicking the button starts the Selector.
My Yahoo openid card is shown on a green background because I have visited the openid consumer (test-id.org) before and I have used this card there before.
Clicking the card image selects the card.
and you can now press "Send" to start the openid dance.
Discovery and Check Immediate are performed:
A "setup needed" is received and the Selector closes and we continue in the main browser window.
The final window: "You passed the test".
Posted by Unknown at 3:19 PM 0 comments
Tuesday, January 26, 2010
interop.ca.com for RSA 2010
A quick visit of the openinfocard card selector to CA's interop site for RSA 2010.
Hm, clicking the purple-i does ... nothing; but clicking the link next to it does the job.
Now clicking the purple-i - either on the page or on the URL-bar or on the status-bar - starts the selector.
Please note the card with the name "sechs" has a green background because I used it at this site before. Noteworthy too: The selector shows Verisign's issuer logo of CA's SSL certificate.
Please update your openinfocard selector to the latest version before trying this interop.
Posted by Unknown at 8:41 AM 0 comments
Monday, January 11, 2010
Microsoft Update Certificate Woes
When I choose "Start -> Microsoft Update" on my Windows system IE starts and shows http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de .
Security paranoid as I am I have HTTPS://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de in my list of "trusted" sites but not the HTTP-site. I am willing to pay the price to have to add the "s" after "http" every time. No problem.
What annoys me is that since some time ago the certificate is issued to "www.update.microsoft.com" but not for "update.microsoft.com".
I admit that maybe I am not supposed to visit this site because I edited the URL by hand but come on Microsoft: Please buy another certificate or configure the server to redirect me to the one and only with the correct certificate. (This prepending "www" to every webserver is stupid anyway. Leave that to the companies that are 90% marketing and 10% feature)
All OS-updates should be over HTTPS anyway. CPUs are cheap! Buy some more if the encryption is a performance issue. I want that extra SSL security.
Posted by Unknown at 9:47 AM 0 comments
Labels: certificate, Microsoft