Sorry guys I've had a busy week and I'm only on the digest list so Ray's message took a while to come through.
Matt - I agree that an application should only have one login form (if it's a standard username* and a password is included we can create a UsernamePasswordAuthenticationToken and then call AuthenticationManager.authenticate). I'm also not convinced about the use of email addresses as OpenIDs as lots of existing sites use email for usernames. As for absolute transparency, some OpenID providers (e.g. myopenid) have a 'safe mode' that will only allow you to authenticate on their site... Ray - * Regex matching of the submitted principal makes perfect sense. I've currently got a TODO in the OpenIDAuthenticationProvider for mapping URLs to usernames before calling the AuthoritiesPopulator - it should be configurable but with sufficient documentation to try to prevent misconfiguration that might allow alice.evilopenid.com to access a local alice account. This becomes more critical if the webapp is also an OpenID provider and you allow users to use https://openid.mysite.com/{username} - (thinking out loud) in which case the OpenIDAuthenticationProvider could take a Map of openid.server domains to patterns (or some form of transformer bean)... It would be useful to refactor the CasAuthoritiesPopulator/DaoCasAuthoritiesPopulator etc. to an sso package (maybe rationalise the LdapAuthoritiesPopulator and the CasAuthoritiesPopulator interfaces?). For backwards compatibility it might be nice to make org.acegisecurity.providers.cas.populator.DaoCasAuthoritiesPopulator an empty subclass of the new DaoSsoAuthoritiesPopulator. I'll finish off the refactoring to abstract the JanRain consumer library, add some unit tests, move the package from com.opsera.acegi to org.acegisecurity and rewrite the steps in my initial reply to Matt for the reference guide and then zip it all up for the sandbox (I'll aim for early next week). Then I need to find the time to resume the server implementation; my primary concern is around seamlessly tying the user interaction into the flow - Myopenid makes you authenticate in a second window before clicking continue to be returned to the consuming site. Current idea is to configure the OpenID server authentication servlet URL as a secured resource - assume I may need to modify some Acegi code to allow the data to be rePOSTed to the servlet (or appended as a query string and then I can implement doGet on the servlet). Cheers, Robin -----Original Message----- Subject: Acegisecurity-developer Digest, Vol 11, Issue 2 To: acegisecurity-developer@lists.sourceforge.net Reply-to: acegisecurity-developer@lists.sourceforge.net Date: Tue, 13 Mar 2007 08:40:43 -0700 <snip> Date: Thu, 8 Mar 2007 08:41:46 -0600 From: "Ray Krueger" Subject: Re: [Acegisecurity-developer] OpenID support I am interested in getting involved in this effort as well. I agree with the transparency of the OpenId vs Username field. One of the ideas that I lean towards is following a url pattern, rather than just the host.domain pattern. DHH (the rails guy) talked about this exact subject a few days ago on his blog: http://www.loudthinking.com/arc/000606.html Following a URL pattern makes it extremely easy to tell the difference between the two. Providing a means in the code to define an 'openIdMatchPattern' that defines a regex to tell the difference would be the best way to go on our end in Acegi. Also, there several openId libraries out there, it would be senseless to build the authentication and delegation functionalities directly into Acegi. I think Robin is definitely on the right track there. I don't like the idea of our OpenID support calling off into our CAS code though, if the functionality there is useful outside of CAS it should get refactored into a new home. Robin, if you would like to get some other folks involved zip up the code and email it to me directly. I'll find a home for it in the sandbox and we can all start taking a look at it. -----Original Message----- From: Matt Raible Sent: 08 March 2007 14:20 To: Robin.Bramley Cc: acegisecurity-developer@lists.sourceforge.net Subject: Re: [Acegisecurity-developer] OpenID support That's great to hear someone is working on this. However, I'm wondering if it's possible to make it more transparent to the user. For example, have some sort of bean or filter that's OpenID aware and has a list of servers to talk to. If there's two dots in the username, Acegi attempts to authenticate with open id (through some background call that's transparent to the user). If not, it attempts normal authentication. Is there any problem with providing this type of transparency? I like the idea behind having the openid string and username come from the same text box. http://www.pjhyett.com/posts/213-openid-isn-t-going-to-work-unless I don't know about the fake e-mail address in the above post, but I like the idea of assuming openid when no password is entered. Matt ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
