[Acegisecurity-developer] OpenID support updated

[Ray Krueger]

I've been sitting on this for far too long and finally committed the changes.

I've committed the OpenId4java support and an
OpenIdAuthenticationProcessingFilter built to replace the Servlet that
is in there now. I've been poking around with it for a while...
http://raykrueger.blogspot.com/search/label/Acegi

I had a contacts sample working, but it was a giant pain to deploy it
as our samples have no way of seeing the sandbox in the build. I hope
to build a sample separately; but don't anyone go holding their
breath.

Now what we need is other folks to jump in and play with it, test it,
break it, and most importantly PATCH IT! I know Phillip Rhodes was
offering his assistance at one point, that would be fantastic. Maybe
"jdwyah" would like to help out too if he's listening?

Our OpenId support is definitely going to need some more attention
than mine, I don't have much to give right now.

Have at it!
-Ray

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Re: [Acegisecurity-developer] OpenID support added to sandbox!

[Ray Krueger]

I've already started working on some refactoring. I believe I can
reduce the OpenIDResponseProcessingFilter and
OpenIDLoginInitiationServlet into one standard OpenIdProcessingFilter.

This also has the side effect of increasing test coverage by reducing
the amount of code to test :)

On 4/20/07, Ray Krueger <[EMAIL PROTECTED]> wrote:
> Thanks to the efforts of Robin Bramley; we now have a first draft of
> OpenID support in the sandbox. The code is mostly as-is from when
> Robin submitted sent it to me. I've done all the standard jalopy
> formatting of the code so it blends in and has the proper file
> headers.
>
> I've noted two basic Todo items for the code:
> * Improve test coverage
> * Replace OpenIDLoginInitiationServlet with a Filter to apply to our
> normal FilterChain
>
> I apologize for taking so long to get it together and get it
> committed. Everyone has their priorities to manage!
>
> Thanks again to Robin for the excellent submission!
>

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

[Acegisecurity-developer] OpenID support added to sandbox!

[Ray Krueger]

Thanks to the efforts of Robin Bramley; we now have a first draft of
OpenID support in the sandbox. The code is mostly as-is from when
Robin submitted sent it to me. I've done all the standard jalopy
formatting of the code so it blends in and has the proper file
headers.

I've noted two basic Todo items for the code:
* Improve test coverage
* Replace OpenIDLoginInitiationServlet with a Filter to apply to our
normal FilterChain

I apologize for taking so long to get it together and get it
committed. Everyone has their priorities to manage!

Thanks again to Robin for the excellent submission!

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Re: [Acegisecurity-developer] OpenID support

[Ray Krueger]

I have the zip in my inbox Robin, thanks!
I'll sort all this out and get it into the sandbox asap.

On 3/15/07, Robin.Bramley <[EMAIL PROTECTED]> wrote:
> The zip of the Acegi OpenID Consumer code is on it's way to Ray - so
> will hopefully hit the sandbox soon.
>
> It's using the JanRain library at the moment, I'm getting exceptions
> from the SXIP library so I haven't included that implementation of the
> OpenIDConsumer interface.
>
> Cheers,
>
> Robin
>
>
> -
> 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

Re: [Acegisecurity-developer] OpenID support

[Robin.Bramley]

The zip of the Acegi OpenID Consumer code is on it's way to Ray - so
will hopefully hit the sandbox soon.

It's using the JanRain library at the moment, I'm getting exceptions
from the SXIP library so I haven't included that implementation of the
OpenIDConsumer interface.

Cheers,

Robin


-
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

Re: [Acegisecurity-developer] OpenID support

[Matt Raible]

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: acegisecurity-developer@lists.sourceforge.net
> > Reply-to: acegisecurity-developer@lists.sourceforge.net
> > Date: Tue, 13 Mar 2007 08:40:43 -0700
> >
> > 
> >
> > 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 calli

Re: [Acegisecurity-developer] OpenID support

[Ray Krueger]

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
>
> 
>
> 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

Re: [Acegisecurity-developer] OpenID support

[Robin.Bramley]

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



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 

Re: [Acegisecurity-developer] OpenID support

[Ray Krueger]

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.

On 3/8/07, Matt Raible <[EMAIL PROTECTED]> wrote:
> 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
>
> On 3/8/07, Robin.Bramley <[EMAIL PROTECTED]> wrote:
> > Hi Matt,
> >
> > I'm currently working on OpenID ui, provider & adaptor classes for Acegi
> > - with the intention of tidying them up and contributing them to the
> > project.
> >
> > I've got a prototype Acegi OpenID consumer authentication working (using
> > the JanRain library - I plan to abstract the library support).
> > The flow is:
> >  1. User requests a secured page and the
> > AuthenticationProcessingFilterEntryPoint (configured on the
> > ExceptionTranslationFilter) sends the user off to an OpenID login form
> >  2. The user enters their OpenID (e.g. rbramley.myopenid.com) and
> > submits the form
> >  3. The form POSTs to /j_acegi_openid mapped to
> > OpenIDLoginInitiationServlet (uses Spring web app context to get the
> > JanRain OpenID Store)
> >  4. The Consumer.begin method looks up the identity page, associates to
> > the server etc.
> >  5. The servlet redirects the user to the OpenID server (e.g.
> > myopenid.com), setting the return to URL as
> > /j_acegi_openid_security_check
> >  6. The user logs on and the OpenID server returns the user
> >  7. Acegi passes the request to the OpenIDProcessingFilter based on the
> > filterProcessesUrl property
> >  8. The Consumer.complete method provides a response object which is
> > wrapped in an OpenIDAuthenticationToken
> >  9. This is passed to the OpenIDAuthenticationProvider (via the
> > AuthenticationManager)
> >  10. If the response is a successul authentication, the auth provider
> > uses the CasAuthoritiesPopulator interface to obtain the UserDetails
> >  11. The Authentication is returned and the user sent to the originally
> > requested URL (as stored in the
> > AuthenticationProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY HttpSession
> > attribute by the SecurityEnforcementFilter).
> >
> >
> > The next steps are to finish the OpenID server (may use the openid4java
> > library from sxip) backed by Acegi and then look at how to encapsulate
> > the registration functionality.
> >
> > Cheers,
> >
> > Robin
> >
> > Robin Bramley
> > Opsera
> > www.opsera.com 
> >
> > > Matt Raible
> > > Fri, 29 Dec 2006 15:34:32 -0800
> > >
> > > Are there any plans to support OpenID as a SSO option with Acegi
> > Security?
> > >
> > > http://openid.net 
> > >
> > > We've seen some interest in supporting this with Roller - which uses
> > > Acegi for its security.
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> > > --
> > > http://raibledesigns.com 
> > >
> >
> >
> >
> >
> >
>
>
> --
> 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=so

Re: [Acegisecurity-developer] OpenID support

[Matt Raible]

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

On 3/8/07, Robin.Bramley <[EMAIL PROTECTED]> wrote:
> Hi Matt,
>
> I'm currently working on OpenID ui, provider & adaptor classes for Acegi
> - with the intention of tidying them up and contributing them to the
> project.
>
> I've got a prototype Acegi OpenID consumer authentication working (using
> the JanRain library - I plan to abstract the library support).
> The flow is:
>  1. User requests a secured page and the
> AuthenticationProcessingFilterEntryPoint (configured on the
> ExceptionTranslationFilter) sends the user off to an OpenID login form
>  2. The user enters their OpenID (e.g. rbramley.myopenid.com) and
> submits the form
>  3. The form POSTs to /j_acegi_openid mapped to
> OpenIDLoginInitiationServlet (uses Spring web app context to get the
> JanRain OpenID Store)
>  4. The Consumer.begin method looks up the identity page, associates to
> the server etc.
>  5. The servlet redirects the user to the OpenID server (e.g.
> myopenid.com), setting the return to URL as
> /j_acegi_openid_security_check
>  6. The user logs on and the OpenID server returns the user
>  7. Acegi passes the request to the OpenIDProcessingFilter based on the
> filterProcessesUrl property
>  8. The Consumer.complete method provides a response object which is
> wrapped in an OpenIDAuthenticationToken
>  9. This is passed to the OpenIDAuthenticationProvider (via the
> AuthenticationManager)
>  10. If the response is a successul authentication, the auth provider
> uses the CasAuthoritiesPopulator interface to obtain the UserDetails
>  11. The Authentication is returned and the user sent to the originally
> requested URL (as stored in the
> AuthenticationProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY HttpSession
> attribute by the SecurityEnforcementFilter).
>
>
> The next steps are to finish the OpenID server (may use the openid4java
> library from sxip) backed by Acegi and then look at how to encapsulate
> the registration functionality.
>
> Cheers,
>
> Robin
>
> Robin Bramley
> Opsera
> www.opsera.com 
>
> > Matt Raible
> > Fri, 29 Dec 2006 15:34:32 -0800
> >
> > Are there any plans to support OpenID as a SSO option with Acegi
> Security?
> >
> > http://openid.net 
> >
> > We've seen some interest in supporting this with Roller - which uses
> > Acegi for its security.
> >
> > Thanks,
> >
> > Matt
> >
> > --
> > http://raibledesigns.com 
> >
>
>
>
>
>


-- 
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
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

[Acegisecurity-developer] OpenID support?

[Matt Raible]

Are there any plans to support OpenID as a SSO option with Acegi Security?

http://openid.net

We've seen some interest in supporting this with Roller - which uses
Acegi for its security.

Thanks,

Matt

-- 
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
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer