Adding InfoCard login to a J2EE Web Application
PIN protect your Personal Infocard
Many RPs offer passwordless login with Personal Infocards.
But, what if you share your Windows login - this is the case where you need to protect your Infocard with a PIN.
CardSapce supports you to PIN protect your Infocard.
WSO2 Mashup Server v1.0 Beta added Infocard support...
Please visit Mashup Server community site, Signup for a new account, Signin and register a Personal Infocard with your account. Now you can login with your Personal Infocard.
Link to register your Infocard is available on your profile page.
Password-less login support with myOpenID
This is another outcome of OpenID Cardspace integration, to the OpenID community.
With the aid of Personal Information cards, it's possible to implement password-less login.
With this apporach, most of the cases you will signup with a Personal Information card. The beauty of Personal cards is, CardSpace creates a unique id [ppid] for each information card, relying party combination. See the screen-shot below. I am using the same Personal Information card to signin to many relying parties.
Okay - what happens if we lose the Infocard - say we clear the CardSpace. Can we use another personal card with the same set of claims to login to my RP. No, you won't - remember I said, ppid, is a combination of Infocard + RP, so once you lost your Infocard you can do nothing to login to the same RP with the same profile.But, RPs may have different ways to recover your account/profile - remember, the 'secret question' in a normal username/password case.
There are two patterns found, adapted by many sites to implement passwordless login.
1. Signup directly with your Personal Information card.
2. Signup with a username/password based account and associate any number of Personal Infocards with it. So - later you can have passwordless login with any of the associated Infocards. Also - with this approach if you lose your Infocard you need not to worry too much, you have the other option - username/password login.
The above two are the most common ones. In addition to those myOpenID also supports removing the password from your account [deviates slightly from 2] - once you have linked your account with a Personal Infocard.
Also, it's a good practice to backup your Infocards. Windows Cardspace let you have encrypted backups.
With the aid of Personal Information cards, it's possible to implement password-less login.
With this apporach, most of the cases you will signup with a Personal Information card. The beauty of Personal cards is, CardSpace creates a unique id [ppid] for each information card, relying party combination. See the screen-shot below. I am using the same Personal Information card to signin to many relying parties.
Okay - what happens if we lose the Infocard - say we clear the CardSpace. Can we use another personal card with the same set of claims to login to my RP. No, you won't - remember I said, ppid, is a combination of Infocard + RP, so once you lost your Infocard you can do nothing to login to the same RP with the same profile.But, RPs may have different ways to recover your account/profile - remember, the 'secret question' in a normal username/password case.
There are two patterns found, adapted by many sites to implement passwordless login.
1. Signup directly with your Personal Information card.
2. Signup with a username/password based account and associate any number of Personal Infocards with it. So - later you can have passwordless login with any of the associated Infocards. Also - with this approach if you lose your Infocard you need not to worry too much, you have the other option - username/password login.
The above two are the most common ones. In addition to those myOpenID also supports removing the password from your account [deviates slightly from 2] - once you have linked your account with a Personal Infocard.
Also, it's a good practice to backup your Infocards. Windows Cardspace let you have encrypted backups.
Windows registry settings for Microsoft CardSpace
1. HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-informationCard
Internet Explorer 7.0 supports information cards using a MIME handler extension called Microsoft Information Card IE Helper, available from icardie.dll. The above registry key links the MIME type for information cards to the handler.
2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\InformationCard Token Provider
The handler is responsible for calling the Identity Selector, passing parameters specified by the object tag or XHTML binary behavior. For Internet Explorer 7.0, the identity selector defaults to Windows CardSpace, indicated by the above registry entry.
3. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Default Behaviors\INFORMATIONCARD
For the object tag syntax, the MIME handler is triggered through the InformationCardSigninHelper Class, enabled by default in the Internet Explorer 7.0 add-ons.If this add-on is disabled, the object tag will not trigger identity selection, but this setting has no effect on XHTML syntax. The XHTML information card behavior is configured in a string entry labeled INFORMATIONCARD under the registry key.
The object tag uses the MIME type application/x-informationCard:
The information card binary behavior can be specified in XHTML by using a #default#informationCard behavior in the <informationCard> element:
<object id="informationCard" name="informationCard"
type="application/x-informationCard">
...
<object>
<ic:informationCard name="xmlToken"
style="behavior:url(#default#informationCard)" ... >
...
</ic:informationCard>
Infocards with myOpenID
1. Go to myOpenID and signup for a new OpenID [if you already have a one from myOpenID this step is not necessary]- it is also possible to signup using a self-issued Infocard, in that case steps 2 to 5 are not necessary - those explain how to associate an Infocard with an existing myOpenID account.
2. Create a self-issued Infocard in your Identity Selector.
3. If you are aleady signed in to OpenID, sign out and go to the SignIn page.
4. Instead of typing your username and password, simply click on the link, "Sign in with an Information Card" - to select the self-issued Infocard that you just created, from the Identity selector.
5. Once you submit the Infocard, you'll be prompted for the myOpenID username/password to associate the Infocard you submit with your OpenID - this is only a one time step.
6. Now you are done. Whenever you are redirected to myOpenID for authentication you can simply login with your self-issued Infocard, which you registered with your myOpenID - OpenID.
Integrating OpenID and Infocard
Kim Cameron's approach is very much different from what is proposed in this spec by Sxip Identity.This proposes a new term - 'OpenID Inforcard'. Please refer my previous post to see a demonstration on OpenID Infocards and this post to find the differences between normal Infocard and OpenID Infocard approaches.
Well, if we go by Kim Cameron's proposal, we need to modify the OpenID Provider in to an Infocard Relying party.But, what is the gain? We make the OpenID flow phishing resistance.Anyway, if that is the only benefit - do we have to (really) go ahead with it? There are many other approaches to make OpenID, phishing resistance without touching the current OpenID Provider implementation. One such approach is to use the SeatBelt plugin for Firefox. But, with this, are we asking 'too' much from the user, since we pass the responsibility of protecting from phishing, towards the user.Anyway - my final thoughts on this is, Kim's proposal will definitely will be a marketing plus for OpenID Providers, if they, themselves add the phishing resistance to OpenID flow using Infocards.
Going back to the OpenID Infocard proposal - I can't really understand the benefit. It's almost same as the normal Infocard approach, except the use of OpenIDToken inside the RequestedSecurityToken, instead of SAML. In this post Mike Jones lists the benefits of OpenID Infocards against 'normal' OpenID.
1. There’s no OpenID string to type when you use your OpenID
2. This is a phishing-resistant authentication method.
3. It lets you recognize and choose your OpenID visually, based on the card graphics supplied by the OpenID provider.
Yes - I agree with all, but is there a point of using OpenID Infocards[OpenIDToken supported] against Infocards[SAML supported]?
Diffie-Hellman Key Exchange
https://www.youtube.com/watch?v=BKkg5s9Jv3kIn OpenID a shared secret is being established between the Relying Party and the OpenID Provider using the Diffie-Hellman Key Exchange and this is used to sign all the messages flow between two parties.
Following is a nice video on Diffie-Hellman Key Exchange, from YouTube.
Following is a nice video on Diffie-Hellman Key Exchange, from YouTube.
Turn your blog Url to your OpenID
Step 1:
Create your OpenID from an OpenID provider - for example I have the OpenID prabath.myopenid.com from myOpenID.com
Step 2:
So, now I have my OpenID, where I can use it to sign-in to any OpenID relying party. But, what if my OpenID provider shuts down business. I loose my OpenID.. :( The real issue here is I do not own my OpenID Url, that is prabath.myopenid.com.
Step 3:
To overcome the issue we found in Step 2, lets have our own blog Url, as our OpenID - so I own it.
In this case my blog Url is psiriwardena.blogspot.com. Let's see how we can map this to any OpenID aquired by any OpenID provider.
Step 4:
Go to your blog, edit the template and add the following two lines inside the <head></head> element.
<link href='http://www.myopenid.com/server' rel='openid.server'/>
<link href='http://prabath.myopenid.com/' rel='openid.delegate'/>
In the first line I set a reference to my OpenID provider. This value is common to all OpenIDs aquired from myOpenID.
In the second line I specify my OpenID, which I aquired from the myOpenID - so set this to your OpenID.
No we are done.
Step 5:
Now lets go to an OpenID relying party and when promted for the OpenID, I'll be typing psiriwardena.blogspot.com and I am done.
The benefit gain by this approach is, you can have one OpenID and can map it to any OpenID you obtained from any OpenID provider, whenever you want.
Enjoy!
Infocards Vs OpenID Infocards
In this post, I'll be discussing the modifications required for the Microsoft's identity metasystem, to support OpenID Infocards. Identity metasystem consists of three parts. Identity Provider, Relying Party and the Identity Selector. Let's take one by one.
First, it would be better to identify the protocol flow under the OpenID Infocard scenario.
1.User acquires an OpenID Infocard from an OpenID Infocard enabled Identity Provider and installs it in his Identity Selector.
2.User browses to an OpenID Relying Party [RP]
3.User invokes an element on the page to send an OpenID token to the Relying Party. In this case user will be clicking on an image, just like the following – which says this RP accepts OpenID Infocards. [ Same as 'We accept American Express' in your nearest shopping mall]
4.Identity Selector detects the "application/x-informationCard" OBJECT element on the RP's login page, requesting an OpenID token. This is same as in the normal Infocard scenario. Basically type="application/x-informationCard" indicates to the browser that it has to invoke the underlying Identity Selector and passes the associated attributes to the Identity Selector. In the case of an OpenID Infocard we set the value of the parameter “tokenType” to “http://specs.openid.net/auth/2.0”
5. User selects an OpenID Information Card to use. In this case Identity Selector only presents the Inforcards which are of 'tokentype', “http://specs.openid.net/auth/2.0” for user selection.
6.Identity Selector sends a Request Security Token (RST) to the Security Token Service (STS) endpoint of the Identoty Provider that issued the card.
7.Identity Provider issues an OpenID Authentication Response, encodes that response in an OpenID token, and encapsulates the token in a Request Security Token Response (RSTR).
8.Identity Provider returns the RSTR to the Identity Selector.
9.Identity Selector POSTs the response back to the RP.
10.RP extracts the OpenID Authentication response from the OpenID token and returns to the normal OpenID verification flow.
Basically, in most of the cases the steps are exactly same as in a normal Infocard case. Only difference is, in each case we have to handle the OpenID token [instead of SAML token], as well as we also need to support OpenID Identifier claim type [http://schema.openid.net/2007/05/claims/identifier].
So, both the Identity Provider, as well as the Relying Party need to be able to identify and handle OpenID tokens, while the Identity Selector's behaviour is unchanged, since the tokens are opaque to Identity Selectors.
First, it would be better to identify the protocol flow under the OpenID Infocard scenario.
1.User acquires an OpenID Infocard from an OpenID Infocard enabled Identity Provider and installs it in his Identity Selector.
2.User browses to an OpenID Relying Party [RP]
3.User invokes an element on the page to send an OpenID token to the Relying Party. In this case user will be clicking on an image, just like the following – which says this RP accepts OpenID Infocards. [ Same as 'We accept American Express' in your nearest shopping mall]
4.Identity Selector detects the "application/x-informationCard" OBJECT element on the RP's login page, requesting an OpenID token. This is same as in the normal Infocard scenario. Basically type="application/x-informationCard" indicates to the browser that it has to invoke the underlying Identity Selector and passes the associated attributes to the Identity Selector. In the case of an OpenID Infocard we set the value of the parameter “tokenType” to “http://specs.openid.net/auth/2.0”
5. User selects an OpenID Information Card to use. In this case Identity Selector only presents the Inforcards which are of 'tokentype', “http://specs.openid.net/auth/2.0” for user selection.
6.Identity Selector sends a Request Security Token (RST) to the Security Token Service (STS) endpoint of the Identoty Provider that issued the card.
7.Identity Provider issues an OpenID Authentication Response, encodes that response in an OpenID token, and encapsulates the token in a Request Security Token Response (RSTR).
8.Identity Provider returns the RSTR to the Identity Selector.
9.Identity Selector POSTs the response back to the RP.
10.RP extracts the OpenID Authentication response from the OpenID token and returns to the normal OpenID verification flow.
Basically, in most of the cases the steps are exactly same as in a normal Infocard case. Only difference is, in each case we have to handle the OpenID token [instead of SAML token], as well as we also need to support OpenID Identifier claim type [http://schema.openid.net/2007/05/claims/identifier].
So, both the Identity Provider, as well as the Relying Party need to be able to identify and handle OpenID tokens, while the Identity Selector's behaviour is unchanged, since the tokens are opaque to Identity Selectors.
OpenID with Cardspace
1. MSDN Webcast: Windows CardSpace (Level 200)
2. MSDN Webcast: Exploring Windows CardSpace
3. MSDN Webcast: Introduction to Windows CardSpace
So, we are back to the subject, what OpenID has to do with Cardspace? Cardspace [Infocards] removes the issue of phishing attacks - while OpenID not. [but, still there are few ways you can make OpenIDs not susceptible to phishing attacks - one such way is the SeatBelt addon for FireFox].With OpenID, at the relying party,when you type your OpenID, you are redirected to the OpenID Provider site for authentication and again redirected back to the original site [the relying party]. With OpenID Infocard, we remove this redirection step. At the same time - we loose the SSO [Single Sign-on] capability, which is normally available with OpenID, but not with Infocards.
So - get ready for a demonstration.
1. Go to https://openidcards.sxip.com/TokenService/CreateProfile.html, and create a profile for you - just a user name and a password.
2. Go to https://openidcards.sxip.com/TokenService/GenerateCardByUsername.html [openID Infocard Provider], enter Card Name, User Name and Password - which you created in Step 1, then Click to download the OpenID Infocard.
3. Make sure you have .NET 3.0 and IE 7 installed. Just click on the downloaded file and install it in the Windows Cardspace.
4. Now go to the relying party site - https://openidcards.sxip.com/demorp/, Click on the image to login with your OpenID Infocard.
5. Now the Identity Selector will pop-up - so you can select the Infocard, that you installed - select it and 'Send' - enter your password.
6. Now you are done and on the required page, with no redirections.
This is a simple and very basic demonstration - and it hides your OpenID till you finally logged in.
At WSO2,we have the WSO2 Identity Solution - which enables LAMP and Java websites to provide strong authentication based on the new interoperable Microsoft CardSpace technology. Right now we are also working on integrating OpenID support for WSO2 IS.
Comment on Blogger blogs with OpenID
After just two short weeks of testing on Blogger in draft, OpenID commenting is now available for all Blogger blogs from yesterday.
In one of my previous posts I mentioned that OpenID being tested for Blogger blogs and the same post describes all the steps you need to obtain an OpenID.
So, go ahead, create your OpenID and start commenting on Blogger blogs. In future this feature will be added to other blogs as well - so, you only require one id to comment on any blog.
WSO2 Identity Solution 1.0 RELEASED!
WSO2 Identity Solution team announced the 1.0 release of the WSO2 Identity Solution.
The WSO2 Identity Solution enables LAMP and Java websites to provide strong authentication based on the new interoperable Microsoft CardSpace technology, which is built on the open standards Security Assertion Mark-up Language (SAML) and WS-Trust. WSO2's new open source security offering features an easy-to-use Identity Provider that is controlled by a simple Web-based management console and supports interoperability with multiple vendors' CardSpace components, including those provided by Microsoft .NET. The WSO2 Identity Solution also works with enterprises'
current identity directories, such as those based on the Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory, allowing them to leverage their existing infrastructure. In addition to the Identity Provider WSO2 Identity Solution provides a Relying Party Component Set which plugs into the most common web servers to add support for CardSpace authentication.
You can download the release artifacts from here :
http://dist.wso2.org/products/solutions/identity/1.0/
Key Features in this 1.0 Release are :
===============================================================
* Identity provider
- Simple management console
- Ability to connect to custom user stores
(LDAP/Microsoft ActiveDirectory, JDBC)
- Built in user store
- Support for the CardSpace default claim set
- Support for custom claim dialects and claims types
- Statistics/reporting/audit trail
- Ability to revoke information cards
- Issues information cards based on username-token credential
and self issued credential
* Apache HTTPD relying party module - mod_cspace
- CardSpace authentication support for static web content
- Support for any server side scripting language supported
by Apache2
- Easy integration interface for developers
- Support for content management frameworks such as
Drupal, MediaWiki
* Java Servlet Filter relying party component
- Provides an intuitive plug-in for J2EE web application
developers to enable CardSpace authentication
- Supports multi-valued claims
- Supports a set of simple operation
The WSO2 Identity Solution enables LAMP and Java websites to provide strong authentication based on the new interoperable Microsoft CardSpace technology, which is built on the open standards Security Assertion Mark-up Language (SAML) and WS-Trust. WSO2's new open source security offering features an easy-to-use Identity Provider that is controlled by a simple Web-based management console and supports interoperability with multiple vendors' CardSpace components, including those provided by Microsoft .NET. The WSO2 Identity Solution also works with enterprises'
current identity directories, such as those based on the Lightweight Directory Access Protocol (LDAP) and Microsoft Active Directory, allowing them to leverage their existing infrastructure. In addition to the Identity Provider WSO2 Identity Solution provides a Relying Party Component Set which plugs into the most common web servers to add support for CardSpace authentication.
You can download the release artifacts from here :
http://dist.wso2.org/products/solutions/identity/1.0/
Key Features in this 1.0 Release are :
===============================================================
* Identity provider
- Simple management console
- Ability to connect to custom user stores
(LDAP/Microsoft ActiveDirectory, JDBC)
- Built in user store
- Support for the CardSpace default claim set
- Support for custom claim dialects and claims types
- Statistics/reporting/audit trail
- Ability to revoke information cards
- Issues information cards based on username-token credential
and self issued credential
* Apache HTTPD relying party module - mod_cspace
- CardSpace authentication support for static web content
- Support for any server side scripting language supported
by Apache2
- Easy integration interface for developers
- Support for content management frameworks such as
Drupal, MediaWiki
* Java Servlet Filter relying party component
- Provides an intuitive plug-in for J2EE web application
developers to enable CardSpace authentication
- Supports multi-valued claims
- Supports a set of simple operation
OpenID Hands-on
If you have gone through my last post which links to a Google Tech Talk - you know most of the stuff related to OpenID.
OpenID facilitates decentralized single sign on.
First of all you need to have an OpenID - an identifier.You can get this through an OpenID Provider. myOpenID is such an OpenID provider - which costs you nothing. Once you are there - you can sign up for a new OpenID.
Now you have an OpenID as well as a password. It's time to use it. LiveJournal is one of the OpenID consumers, where you can 'sign in' with your OpenID. Once you enter your OpenID there, you'll be taken to your OpenID Provider [myOpenID] for authentication - where you can enter your password. Once done - you are logged into the LiveJournal.
Similarly, the same OpenID can be used in many other sites as well.
Blogger in draft is another such OpenID consumer.You can add comments to this post - by signing in with your OpenID.
This removes the issue of having multiple passwords and duplicating the same profile accross many sites.
OpenID facilitates decentralized single sign on.
First of all you need to have an OpenID - an identifier.You can get this through an OpenID Provider. myOpenID is such an OpenID provider - which costs you nothing. Once you are there - you can sign up for a new OpenID.
Now you have an OpenID as well as a password. It's time to use it. LiveJournal is one of the OpenID consumers, where you can 'sign in' with your OpenID. Once you enter your OpenID there, you'll be taken to your OpenID Provider [myOpenID] for authentication - where you can enter your password. Once done - you are logged into the LiveJournal.
Similarly, the same OpenID can be used in many other sites as well.
Blogger in draft is another such OpenID consumer.You can add comments to this post - by signing in with your OpenID.
This removes the issue of having multiple passwords and duplicating the same profile accross many sites.
Subscribe to:
Posts (Atom)