Awesome :) What else is there to say? On 3/14/07, Robin.Bramley <[EMAIL PROTECTED]> wrote: > 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 >
------------------------------------------------------------------------- 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
