Showing posts with label OpenID. Show all posts
Showing posts with label OpenID. Show all posts
Easy login plans gather pace
Read more here...
Google moves towards sso with OpenID
In other words - Google acts as an OpenID Provider - you may recall that even your Blogger urls are OpenID enabled.
Google's support to OpenID is through the OpenID 2.0 Directed Identity protocol.
Directed Identity is a term introduced with the seven laws of Identity and it says,
"A universal identity system must support both ‘Omni-directional’ identifiers for use by public entities and ‘unidirectional’ identifiers for use by private entities, thus facilitating discovery while preventing un-necessary release of correlation handles."
Under the OpenID terminology 'Omni-directional’ identifier is equivalent to the OP-Local identifier.
With Google, you can login to any OpenID RP by entering Google OP-Local Identifier, that is https://www.google.com/accounts/o8/id.
OpenID Authenticator for Tomcat
1. BASIC - org.apache.catalina.authenticator.BasicAuthenticator
2. FORM - org.apache.catalina.authenticator.FormAuthenticator
3. DIGEST - org.apache.catalina.authenticator.DigestAuthenticator
4. CLIENT-CERT - org.apache.catalina.authenticator.SSLAuthenticator
My previous post explains how BASIC authentication works with Tomcat.
In this post, we'll be adding a new type of Authenticator to Tomcat.
5. OPENID - org.wso2.OpenIDAuthenticator
With this you can protect your web resources with OpenID authentication.
I am using WSO2 OpenID Relying Party components which do ship with WSO2 Identity Solution.
Let's get started.
First we need to configure Tomcat to use our custom Authenticator.
Extract [CATALINA_HOME]\server\lib\catalina.jar and edit the file \org\apache\catalina\startup\Authenticators.properties to look like following - simply adding our Authenticator to it.
# These must match the allowed values for auth-method as defined by the spec BASIC=org.apache.catalina.authenticator.BasicAuthenticator CLIENT-CERT=org.apache.catalina.authenticator.SSLAuthenticator DIGEST=org.apache.catalina.authenticator.DigestAuthenticator FORM=org.apache.catalina.authenticator.FormAuthenticator NONE=org.apache.catalina.authenticator.NonLoginAuthenticator OPENID=org.wso2.OpenIDAuthenticatorNow we need to re-pack the extracted jar with our change to catalina.jar and keep it in it's original location.
You can download other dependency jars from here.
Copy the jars inside [ZIP_FILE]\jars to [CATALINA_HOME]\server\lib and the jars from [ZIP_FILE]\endorsed to [CATALINA_HOME]\common\endorsed.
That's it with Tomcat configuration.
Now, let's see how we can configure OPENID authentication for our webapp.
It's basically the same way you configure BASIC or any other auth-method for your web app.
You can copy [ZIP_FILE]\demo-app folder to [CATALINA_HOME]\webapps.
Let's have a look at [CATALINA_HOME]\webapps\demo-app\WEB-INF\web.xml.
<web-app> <security-constraint> <web-resource-collection> <web-resource-name>secured resources</web-resource-name> <url-pattern>/web/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>OPENID</auth-method> <form-login-config> <form-login-page>/openid-login.jsp</form-login-page> <form-error-page>/denied.jsp</form-error-page> </form-login-config> </login-config> </web-app>Here, the openid-login.jsp and denied.jsp pages are not application specific - so can be reused across.
All - set, let's see how the demo works - you can also access the online demo from here.
http://localhost:8080/demo-app/ - this is not a protected resource.
Click on the link to, Protected Resource - since this is OpenID protected and you are not authenticated yet, you'll be redirected to the OpenID login page - Type your OpenID there and complete the OpenID authentication routine.
You are on the protected resource now...
I'll just dump the code here for the OpenIDAuthenticator and the OpenIDRealm - it's self-explanatory through comments.
package org.wso2;
import java.io.IOException;
import java.security.Principal;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.Realm;
import org.apache.catalina.Session;
import org.apache.catalina.authenticator.Constants;
import org.apache.catalina.authenticator.FormAuthenticator;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.deploy.LoginConfig;
import org.wso2.solutions.identity.relyingparty.RelyingPartyException;
import org.wso2.solutions.identity.relyingparty.TokenVerifierConstants;
import org.wso2.solutions.identity.relyingparty.openid.OpenIDAuthenticationRequest;
import org.wso2.solutions.identity.relyingparty.openid.OpenIDConsumer;
import org.wso2.solutions.identity.relyingparty.openid.OpenIDRequestType;
import org.wso2.solutions.identity.relyingparty.openid.OpenIDUtil;
/**
* This extends the functionality of FormAuthenticator to facilitate OpenID logins.
*
* @author Prabath Siriwardena @ WSO2
* http://www.wso2.org
* http://blog.facilelogin.com
*
*/
public class OpenIDAuthenticator extends FormAuthenticator {
/**
* {@inheritDoc}
*/
public boolean authenticate(Request request, Response response, LoginConfig config) {
Principal principal = null;
boolean loginAction = false;
boolean isAuthenticated = false;
String requestURI = null;
Realm realm = null;
String openID = null;
// References to objects we will need later
Session session = null;
principal = request.getUserPrincipal();
if (principal != null) {
// We are here because we have being authenticated successfully, before.
return true;
}
// Check whether this is a re-submit of the original request URI after successful
// authentication? If so, forward the *original* request instead.
if (matchRequest(request)) {
return matchRequest(request, response, config);
}
// This should be the OpenID return to url.
requestURI = request.getDecodedRequestURI();
// This request came from the login page - let me login - here are my credentials.
loginAction = (request.getParameter("login") != null);
if (!loginAction) {
// This can be the initial request for the protected resource or being redirected back
// by the OpenID Provider.
if (OpenIDUtil.isOpenIDAuthetication(request)) {
// This is an OpenID response - follow the OpenID protocol
String auth = null;
try {
OpenIDConsumer.getInstance().setSessionAttributes(request);
auth = (String) request.getAttribute(TokenVerifierConstants.SERVLET_ATTR_STATE);
if (auth != null && TokenVerifierConstants.STATE_SUCCESS.equals(auth)) {
isAuthenticated = true;
} else {
forwardToErrorPage(request, response, config);
return (false);
}
} catch (RelyingPartyException e) {
forwardToErrorPage(request, response, config);
return (false);
}
} else {
try {
session = request.getSessionInternal(true);
saveRequest(request, session);
} catch (IOException ioe) {
return (false);
}
request.getSession().setAttribute("requestURI", requestURI);
forwardToLoginPage(request, response, config);
return (false);
}
}
// You are here, because you came here directly from the openid-login page or you are
// authenticated at OP and redircted back.
if (!isAuthenticated) {
// Let's build the OpenID authentication request.
try {
doOpenIDAuthentication(request, response);
return false;
} catch (RelyingPartyException e) {
forwardToErrorPage(request, response, config);
return (false);
}
}
realm = context.getRealm();
session = request.getSessionInternal(false);
if (!(realm instanceof OpenIDRealm)) {
realm = new OpenIDRealm();
context.setRealm(realm);
}
openID = (String) request.getAttribute("openid_identifier");
principal = realm.authenticate(openID, "");
if (principal == null) {
forwardToErrorPage(request, response, config);
return (false);
}
// Save the authenticated Principal in our session
session.setNote(Constants.FORM_PRINCIPAL_NOTE, principal);
// Save the OpenID
session.setNote(Constants.SESS_USERNAME_NOTE, openID);
// We have no password for OpenID
session.setNote(Constants.SESS_PASSWORD_NOTE, "");
// Redirect the user to the original request URI (which will cause
// the original request to be restored)
requestURI = savedRequestURL(session);
try {
response.sendRedirect(response.encodeRedirectURL(requestURI));
} catch (IOException e) {
return (false);
}
return (false);
}
/**
* Performs OpenID authentication
*
* @param request Request we are processing
* @param response Response we are creating
* @throws RelyingPartyException
*/
protected void doOpenIDAuthentication(Request request, Response response)
throws RelyingPartyException {
OpenIDAuthenticationRequest openIDAuthRequest = null;
openIDAuthRequest = new OpenIDAuthenticationRequest(request, response);
openIDAuthRequest.setOpenIDUrl((String) request.getParameter("openIdUrl"));
openIDAuthRequest.addRequestType(OpenIDRequestType.SIMPLE_REGISTRATION);
if (request.getProtocol().equals("HTTP/1.1")) {
openIDAuthRequest.setReturnUrl("http://" + request.getLocalName() + ":"
+ request.getLocalPort() + request.getSession().getAttribute("requestURI"));
} else {
openIDAuthRequest.setReturnUrl("https://" + request.getLocalName() + ":"
+ request.getLocalPort() + request.getSession().getAttribute("requestURI"));
}
OpenIDConsumer.getInstance().doOpenIDAuthentication(openIDAuthRequest);
}
/**
* Check whether this is a re-submit of the original request URI after successful
* authentication? If so, forward the *original* request instead.
*
* @param request Request we are processing
* @param response Response we are creating
* @param config Login configuration describing how authentication should be performed
*/
private boolean matchRequest(Request request, Response response, LoginConfig config) {
Session session = null;
Principal principal = null;
session = request.getSessionInternal(true);
principal = (Principal) session.getNote(Constants.FORM_PRINCIPAL_NOTE);
register(request, response, principal, Constants.FORM_METHOD, (String) session
.getNote(Constants.SESS_USERNAME_NOTE), (String) session
.getNote(Constants.SESS_PASSWORD_NOTE));
// If we're caching principals we no longer need the username
// and password in the session, so remove them
if (cache) {
session.removeNote(Constants.SESS_USERNAME_NOTE);
session.removeNote(Constants.SESS_PASSWORD_NOTE);
}
try {
if (restoreRequest(request, session)) {
return (true);
} else {
response.sendError(HttpServletResponse.SC_BAD_REQUEST);
return (false);
}
} catch (IOException e) {
forwardToErrorPage(request, response, config);
return (false);
}
}
}
package org.wso2;
import java.security.Principal;
import org.apache.catalina.Context;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.deploy.SecurityConstraint;
import org.apache.catalina.realm.GenericPrincipal;
import org.apache.catalina.realm.RealmBase;
/**
* This extends the functionality of RealmBase to facilitate OpenID logins.
*
* @author Prabath Siriwardena @ WSO2
* http://www.wso2.org
* http://blog.facilelogin.com
*
*/
public class OpenIDRealm extends RealmBase {
/**
* No passwords for OpenID
*/
protected String getPassword(String openID) {
return "";
}
/**
* {@inheritDoc}
*/
protected Principal getPrincipal(String OpenID) {
return new GenericPrincipal(this, OpenID, "", null, null);
}
/**
* We have no roles associated.
*/
public boolean hasRole(Principal principal, String role) {
return false;
}
/**
* Give this realm required permissions.
*/
public boolean hasResourcePermission(Request request, Response response,
SecurityConstraint[] constraints, Context context) {
return true;
}
/**
* Realm name
*/
protected String getName() {
return "OpenIDRealm";
}
}
User Centric Authentication using WSO2 Identity Solution
This 3-hour course is designed to provide an understanding of CardSpace/OpenID authentication protocols and how to use Identity Solution components.
The course covers following contents and now open for registration.
- Introduction to Microsoft CardSpace concepts
- Introduction to OpenID
- Enabling a CardSpace/OpenID authentication on sample J2EE web application using WSO2 Identity Solution Java relying party component
- Setting up the Identity Provider with LDAP connecting to an Active Directory
- Setting up the Identity Provider with a custom database with user account details
- Federated Identities with WSO2 Identity Solution
- Using custom claims to enable authorization in web applications
OAuth + OpenID + InfoCard
1. User logs into Facebook with his user credentials.
2. User wants to share images from Flickr with Facebook.
3. OAuth comes into act now.
4. Facebook requests Request_Token from Flickr to access user's photos on his behalf.
5. Since user has not authorized the request, Facebook gets unauthorized Request_Token from Flickr.
6. Now, Facebook will redirect the user to Flickr for authentication.
7. User presents his OpenID at Flickr to get authenticated.
8. Flickr redirects the user to his OpenID Provider for authentication - say myOpenID.
9. User authenticates at the myOpenID with a registered Information Card.
10.On successfull login user is redirected back to Flickr.
11.Now, Flickr will ask the user - whether its okay to give Facebook the access to his photos - and once selected 'yes' - user will be redirected back to Facebook.
12.Now, Facebook will request an Access Token from Flickr.
13.Since the user has authorized - Flickr will grant the access token to Facebook.
14.Now, Facebook can access Flickr to get photos on behalf of the user.
15.Let me summarize what each technology is for.
OAuth - a machine authorisation protocol - gives permission for a system to access your account.
OpenID - provides decentralized single sign on.
InfoCards - provides phishing resistant authentication.
Mooshup: The youngest member of the OpenID family
With this, Mooshup enbles OpenID login - in addition to the Information Card based login, which it had already supported.
Randall says, the OpenID initiative, a 'waste of energy'.
"I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them."
Best practices on selecting better passwords always only provide guidelines for how to select a password which is 'hard to guess' - NOT unbreakable. With this point, I totally agree with Randall - Yes, true - passwords do not seem to be the 'right' solution for digital identity.
He further adds.
"As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code."
Yes, true - information cards provide a cryptographic solution to the authentication problem in a phishing resistant manner.
Even in this case - passwords are not totally taken out of the picture.
A given information card can be backed by a username/password, a self-issued information card or an X.509 token.
Also, in all three cases - if your machine, where you have installed all your Information cards, is protected by username/password - still we have not totally eliminated the risk of using passwords. Anybody who steals your machine username/password can easily use any of your information cards to authenticate in to any of the relying party web sites who accept your information cards.
Here comes the most interesting part of Randall's article.
"We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. OpenID promotes “Single Sign-On”: with it, logging on to one OpenID Web site with one password will grant entrance during that session to all Web sites that accept OpenID credentials."
Oops... I am sorry... I totally disagree.
First I disagree with him on the point about Information cards.
CardSpace has made a good progress in the past and it will definitely in the future. It's not just Microsoft that has taken the CardSpace initiative forward - but it has also attracted many open source vendors as well. For example, WSO2 with it's Identity Solution has support for CardSpace - both as an Identity Provider as well as providing relying party components.
Second - I totally disagree with him on his comments on OpenID.
"...however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative."
When such a comment is made - there needs to be enough facts to elaborate more on it. But, unfortunately there is nothing in it to justify.
Both OpenID and CardSpace are two technologies which support user-centric identity.
When you say - 'OpenID vs CardSpace' - it's simply an invalid statement. It should be 'OpenID and CardSpace'. Both the technologies work together smoothly. Please read this blog post by Kim Cameron.
"...OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site."
This is totally misleading.
OpenID specifications never promote a single way of authenticating users to the OpenID Provider.
It can be username/password ,X.509 certificates or even Information cards.
I can take out many examples from the the web which support many of these authentication mechanisms for user authentication.
Randall, further adds.
"...Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised."
Once again - it seems Randall has misunderstood OpenID as a way of password-based login - sorry, sir - it is not.
Deploying WSO2 Identity Solution over an existing MySQL user store
This post explains how you can customize WSO2 Identity Solution to expose an existing user base residing on a MySQL database - and facilitate them with Information Cards and OpenID logins.
Let me further explain this scenario.
You have a set of users with a set of attributes defined for each.
Now the requirement is your company wants you to assign each of your users an OpenID and also run an OpenID Provider your self - and you need to do minimal changes to the existing system.
I'll explain everything you need to know here in a step-by-step manner.
Setting up the existing environment
- Download WampServer 2.0 from here and install it locally.
- Start the wampserver and run MySQL service.
- Add [WAMP_INSTALLED_LOCATION]\bin\mysql\mysql5.0.51b\bin to the PATH env variable.
:\>mysqladmin -u root password mysql
:\> mysql -u root -p
[type your password : mysql]
mysql> CREATE DATABASE COMPANY_DB;
mysql>USE COMPANY_DB;
mysql>CREATE TABLE `users` (`uid` varchar(60) NOT NULL,`name` varchar(60) NOT NULL,`pass` varchar(32) NOT NULL,`mail` varchar(64) ,`openid` varchar(60) NOT NULL, `firstName` varchar(60) NOT NULL,`lastName` varchar(60) NOT NULL,PRIMARY KEY (`uid`));
mysql>INSERT INTO users VALUES ('prabath','prabath','prabath','prabath@wso2.org','http://localhost:12080/user/prabath','prabath','siriwardena');
mysql>COMMIT;
Now we are done with setting up the existing environment.
You may have already noticed that for my convenience I created the 'users' table with an 'openid' column - which you may not have in your existing 'users' table. In that case you need to alter the table 'users', add the new column 'openid' and populate that column with values derived from the 'uid' column - which will create unique OpenIDs for all your users.
Building & deploying WSO2 Identity Solution from source
- Download the latest code from the SVN repo: https://svn.wso2.org/repos/wso2/trunk/solutions/identity
- Then, from the root directory (say [Identity] ) of the downloaded code.
[Make sure you have installed Maven2]
:\> mvn -Drelease clean install
-The above will create a zip file distribution at [Identity]\modules\distribution\target.
- Unzip the Zip file to a local folder.
- Download MySQL JDBC driver from here and copy the mysql-connector-java-5.1.6-bin.jar to [IS_INSTALLED_DIR]\lib
- You also need to download Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0 from here and copy the two jar files from the extracted jce directory (local_policy.jar and US_export_policy.jar) to $JAVA_HOME/jre/lib/security.
- Start WSO2 Identity Solution with [IS_INSTALLED_DIR]\bin\wso2is.bat
Configuring WSO2 Identity Solution to use MySQL user store
- Go to url : https://localhost:12443/admin and login with admin/admin [user/password] - then select 'User Stores'
- Click 'sampleRealm' link [Here we are using the JDBCRealm to connect to the MySQL database].
- Click 'Edit'
- Set the following properties appropriately and update.
UserCredentialColumn : pass
ConnectionPassword : mysql
ConnectionUserName : root
ColumnNames : mail,openid,firstName,lastName
DriverName : com.mysql.jdbc.Driver
UserNameColumn : uid
ConnectionURL : jdbc:mysql://localhost/COMPANY_DB
UserTable : users
- Click 'Set as Default' against 'sampleRealm'.
- Click on 'Define Claims' and select 'Given name','Surname' & 'Email address' [Dont uncheck any claims which are already selected]
- Click on 'Claim Mappings'.
- Click on 'Given name','Surname','Email address' and 'OpenID', and do the claim mapping appropriately.
- Once done the claim mapping it should look like the following.
- Try login to Identity Solution with your credentials available in MySQL database [ in our case prabath/prabath] - go to the url : https://localhost:12443
- To test your OpenID [http://localhost:12080/user/prabath], Signout first and from the Home page [https://localhost:12443], Click on OpenID and then type your OpenID.
You can find more documentation on WSO2 Identity Solution from here.
Mashup Server ready to ship with OpenID support
OpenID relying party support on Mashup Server is powered by WSO2 Identity Solution relying party components.
Further details on this new release available here.
OpenID with PAPE in plain English
[You may also read this blog post by Nandana on "OpenID, Phishing & PAPE, Are we there yet? "]
Let me first explain what PAPE is.
PAPE stands for OpenID Provider Authentication Policy Extension - which is an extension to the OpenID Authentication.
An extension to OpenID Authentication is a protocol that "piggybacks" on the authentication request and response. Extensions are useful for providing extra information about an authentication request or response as well as providing extra information about the subject of the authentication response.
With PAPE, an OpenID Relying Party can add additional information into the OpenID Authentication request - such as;
1. preferred_auth_policies
2. max_auth_age
Let me explain what each one of them means.
With preferred_auth_policies, an RP can attach zero or more authentication policy URIs that the OP SHOULD conform to when authenticating the user. If multiple policies are requested, the OP SHOULD satisfy as many as it can.
Let me make this much clearer.
If RP wants it's users to be authenticated in a phishing resistant manner, then RP will attach the policy URI, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant as the preferred_auth_policies.
If RP wants it's users to be authenticated in both a phishing resistant manner and a multi-factor way , then RP will attach the policy URIs, http://schemas.openid.net/pape/policies/2007/06/phishing-resistant and http://schemas.openid.net/pape/policies/2007/06/multi-factor as preferred_auth_policies.
One thing I want to emphasize here...
Given the fact that RP requested OP to do the user authentication in such a manner - does not mean OP will follow the exact authentication policy request.
In other words, an RP could request OP to authenticate it's users in a phishing resistant manner - but in case OP does not support phishing resistant authentication, then it will simply authenticate the user with the available method. But... OP will also let the RP know the method it used to authenticate the user. So - it becomes a decision up to the RP to decide whether to let user in or not.
Let's see how this works in a practical scenario.
We have hosted the WSO2 Identity Solution at https://is.test.wso2.org and the PAPE demonstration is available at https://is.test.wso2.org/javarp/.
Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your Yahoo OpenID there.
Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.
In this case an OpenID RP sends a PAPE request to an OP which does not support PAPE [Yes, Yahoo still does not support PAPE].
This is what you get as the response.
Authentication Policies: none
NIST Auth Level: 0
Auth Age: -1
For the time being lets only focus on "Authentication Policies" - here Yahoo OP returns no policies. That is Yahoo has ignored the PAPE request by the RP. So, now RP can decide whether to let user in or not.
Let's try another example. This time we use an OpenID from WSO2 OpenID Provider. You can go there, register yourself and get an OpenID.
WSO2 OpenID Provider supports login with both the username/password and Information Card based logins.
First directly login to the OP and then register a self-issued Information Card with the OP. We'll be using this Information card later-on to login.
Once you are at the demo site, find the section - "OpenID PAPE Demo" and type your WSO2 OpenID [http://is.test.wso2.org/user/test] there.
Select "http://schemas.openid.net/pape/policies/2007/06/phishing-resistant" as your authentication policy.
In this case an OpenID RP sends a PAPE request to an OP which supports PAPE.
So, once you are redidirected to OP for authentication, login with your registered Information card.
You'll get the following as the PAPE reponse.
Authentication Policies: http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
NIST Auth Level: 1
Auth Age: -1
This indicates you've being authenticated in a phishing-resistant manner.
In no means, PAPE does not limit you to the following three authentication policies.
1. http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
2. http://schemas.openid.net/pape/policies/2007/06/multi-factor
3. http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical
Additional policies can be specified elsewhere and used between OPs and RPs.
For example, myOpenID defines the policy URI, http://janrain.com/pape/callverifid.html for it's CallVerifID. In this post I blogged about how CallVerifID works.
Hope, by now it's very much clearer how PAPE works.
There are few things I skipped during the discussion.
Let's go back to them.
In PAPE request, RP also can add the parameter "max_auth_age" as well.
This is an optional parameter in the PAPE request, where the RP may or may not request.
Once max_auth_age is set in the PAPE request, if the End User has not actively authenticated to the OP within that number of seconds [max_auth_age] specified in a manner fitting the requested policies, the OP SHOULD authenticate the End User for this request.
Let's go back to the PAPE response. I skipped explaining two parameters, NIST Auth Level and Auth Age.
If the RP's request included the "max_auth_age" parameter then the OP MUST include "auth_time" [Auth Age] in its response. If "max_auth_age" was not requested, the OP MAY choose to include "auth_time" in its response or just send "-1" as the value.
The NIST Auth Level is the the Assurance Level as defined by the National Institute of Standards and Technology (NIST) corresponding to the authentication method and policies employed by the OP when authenticating the End User.
This value varies from 0 to 4 (inclusive).
Let the rest discover your OpenID relying party
This is a new feature introduced in OpenID Authentication 2.0.
With, RP discovery, you let software agents/OpenID Providers discover your site as an OpenID relying party.
OpenID providers use this feature to automatically verify that a return_to URL in an OpenID request is an OpenID relying party endpoint for the specified realm.
Have you ever seen this warning by Yahoo! - when you trying to use a Yahoo OpenID?
"Warning: This website does not meet Yahoo!'s requirements for website address. Do not share any personal information with this website unless you are certain that it is legitimate. "
This happens because, the relying party web site fails to meet OpenID RP discovery requirements.
Usually, as per the spec RP has to present an XRDS document in the following format, where the OpenID Provider can discover.
When it comes to Yahoo OpenID Provider, it tries to find this XRDS document at the return_to url [return_to url is included in the OpenID authentication request it self].
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://specs.openid.net/auth/2.0/return_to</Type>
<URI>https://is.test.wso2.org/javarp/openidloggedin.jsp</URI>
</Service>
So, make sure you have RP discovery information available at your return_to url.
This is how you do it.
Say for example, if your return_to url is https://is.test.wso2.org/javarp/openidloggedin.jsp, when you set it in the OpenID authentication request, you need to set it as below, with an added parameter.
https://is.test.wso2.org/javarp/openidloggedin.jsp?login=true
Also, you need to set your realm as https://is.test.wso2.org/javarp/openidloggedin.jsp.
If you are using WSO2 OpenID Relying Party components, this is how you set your return_to url and the realm in the authentication request.
[This article explains how to add OpenID support to your RP web site with WSO2 OpenID RP components, please refer the section "Adding OpenID Support with Simple Registration"]
openIDAuthRequest.setRealm("https://is.test.wso2.org/javarp/openidloggedin.jsp");
openIDAuthRequest.setReturnUrl("https://is.test.wso2.org/javarp/openidloggedin.jsp?login=true");
Now, you can differenciate a 'login' request from a 'RP discovery' request.
Your openidloggedin.jsp page will have the logic to present the XRDS document for RP discovery, based on the request.
To see a demonstration of how this works, go to https://is.test.wso2.org/javarp/, and type your Yahoo OpenID at "OpenID Simple Registration Demo".
<%@page import="java.io.PrintWriter"%>
<%
String login= (String) request.getParameter("login");
if (login==null)
{
String xrd = null;
response.setContentType("application/xrds+xml");
xrd = "<xrds:XRDS xmlns:xrds=\"xri://$xrds\" xmlns:openid=\"http://openid.net/xmlns/1.0\" xmlns=\"xri://$xrd*($v*2.0)\">\n" +
"<XRD>\n"+
"<Service xmlns=\"xri://$xrd*($v*2.0)\">\n"+
"<Type>http://specs.openid.net/auth/2.0/return_to</Type>\n"+
"<URI>https://is.test.wso2.org/javarp/openidloggedin.jsp</URI>\n"+
"</Service>\n"+
"</XRD>\n"+
"</xrds:XRDS>";
PrintWriter writer = response.getWriter();
writer.write(xrd);
}
else {
//User logs in... add your logic appropriately
}
%>
Deploying your OpenID relying party behind a proxy
First, lets configure Apache to act as a reverse proxy. I assume your Apache server is running at identity-rp:12081 and your web application is running on Tomcat at http://localhost:12080/javarp. If you have different settings, please do the modifications appropriately.
Do the following changes in the httpd.conf.
Now let's download the latest code from the SVN repo: https://svn.wso2.org/repos/wso2/trunk/solutions/identity
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /javarp http://localhost:12080/javarp
<Location /javarp/>
ProxyPassReverse /
SetOutputFilter proxy-html
RequestHeader unset Accept-Encoding
</Location>
Then, from the root directory (say [Identity] ) of the downloaded code.
[Make sure you have installed Maven2]
:\> mvn -Drelease clean install
You need the following two jars from the build and copy them to your classpath.
1.[Identity]\modules\base\target\wso2is-base-SNAPSHOT.jar
2.[Identity]\modules\token-verifier-core\target\wso2is-token-verifier-core-SNAPSHOT.jar
This article explains how you can develop an OpenID Relying Party web site with WSO2 OpenID RP components. Please refer the section "Adding OpenID Support with Simple Registration".
You also need to do the following changes in addition to what is mentioned in the above document.
Set the return_to url;
openIDAuthRequest.setReturnUrl("http://localhost:12080/javarp/openidcallback.jsp");
Add the following to the web.xml of your web application.
All done and now you are set to run your web application.
<filter>
<filter-name>OpenIDTokenValidator</filter-name>
<filter-class>org.wso2.solutions.identity.relyingparty.servletfilter.OpenIDRelyingPartyFilter</filter-class>
<init-param>
<param-name>MappingHost</param-name>
<param-value>localhost</param-value>
</init-param>
<init-param>
<param-name>MappingPort</param-name>
<param-value>12080</param-value>
</init-param>
<init-param>
<param-name>MappedHost</param-name>
<param-value>identity-rp</param-value>
</init-param>
<init-param>
<param-name>MappedPort</param-name>
<param-value>12081</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>OpenIDTokenValidator</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Start both the Apache and your Tomcat servers and hit the url http://identity-rp:12081/javarp to access your web application.
Demand OpenID...!!!
Demand OpenID support from websites you sign in to every day, using a simple bookmarklet.
More info available here...
Microsoft HealthVault about to add OpenID support
HealthVault is a hub of a network of Web sites, personal health devices and other services that you can use to help manage your health. HealthVault lets you store the information in one central place on the Web.
Sean Nolan, chief architect of Microsoft’s HealthVault talks here about adding OpenID support to HealthVault.
Initially it's going to accept OpenIDs only from Verisign and TrustBearer.
Currently HealthVault uses Windows Live ID for login.
Sean Nolan, chief architect of Microsoft’s HealthVault talks here about adding OpenID support to HealthVault.
Initially it's going to accept OpenIDs only from Verisign and TrustBearer.
Currently HealthVault uses Windows Live ID for login.
Subscribe to:
Posts (Atom)