<bean id="openIDStore" class="com.janrain.openid.store.MemoryStore">
<bean id="openIDConsumer" class="org.acegisecurity.ui.openid.consumers.JanRainOpenIDConsumer">
<property name="store" ref="openIDStore"/>
<bean id="openIDResponseProcess" class="org.acegisecurity.ui.openid.OpenIDResponseProcessingFilter">
<property name="consumer" ref="openIDConsumer"/>
<property name="defaultTargetUrl" value="/site/index.html"/>
<property name="authenticationFailureUrl" value="/site/acegilogin.html?login_error=1"/>
<property name="authenticationManager" ref="authenticationManager"></property>
<property name="rememberMeServices" ref="rememberMeServices"></property>
<bean id="openIDAuthProvider" class="org.acegisecurity.providers.openid.OpenIDAuthenticationProvider">
<property name="ssoAuthoritiesPopulator" ref="userDAO"/>
Once I realized that my userDAO would make a fine ssoAuthoritiesPopulator and I didn't have to go figure out was CAS was all about I was off and running. Happily I rewrote the OpenIDLoginInitiationServlet to be a OpenIDLoginController so I could back out the changed to web.xml, which is a good thing only because everytime I touch it I feel like something somewhere goes haywire.
The last hurdle, of course was that it all tested fine, but that when deployed, req.getServer() would still return "localhost" instead of my domain name. Here's to the power of opensource! Saving peoples butts by letting you put hardcode in the source and recompile ;) Clearly I'm missing something.
Unfortunately functional logging in is was half the battle.
The real difficulty arises when you'd like to figure out what to store as the eventual username in the database & you go to implement the signup process.
may all be the same ID, but they sure aren't the same string. JanRain seems to deal with this ok, and always asks me to lookup something of the form "http://someopenid.myopenid.net/" which seems like it should sort me out.
The trick is when your user goes to create an account. If I just ask them for their ID on the signup page,
Alternatively, I could have them login first, then signup, but if I allow just any old OpenID to login, I end up with these weird sort of 'no-account but I'm technically logged in' users, which makes for a bit of a headache ensuring that they aren't allowed to do things a real user can.
Complicating all of this is that all other manner of things may be acceptable openID identifiers, depending on what FAQ / RFC / random blog posting you read. What's the regular expression that validates an openID identifier when
"=Mary.Jones*Henry" and "=@Example.Corp*Ecuador*Quito"
are valid as well as the above? You've got me.
None of this would be so bad except for the fact that I was hoping to have firstname.lastname@example.org be a nice simple way for users to email themselves information. I suppose that's what you get when you try to reconcile "nice & simple" with the cutting edge nerd street cred of OpenID.
For now, just supporting URL's & not i-names seems to be what most people do, so that's my plan. Not precisely sure what to do about the email thing. I'm hoping that stripping off the http:// and trailing / is a solution, but is "openid.com/bob" a valid openID? I can't seem to find that answer.