FWIW, I saw this post where Jeremy Smith got OpenID working with CAS. Since Acegi integrates with CAS, it's worth noting IMO.
http://blog.case.edu/jms18/2007/03/09/openid_server_integrated_with_cas Matt On 3/14/07, Ray Krueger <[EMAIL PROTECTED]> wrote: > 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: [email protected] > > Reply-to: [email protected] > > 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: [email protected] > > 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 > > [email protected] > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer > -- http://raibledesigns.com ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
