OpenIdWebRingSsoProvider into MVC project

[Joao Leme]

Trying to implement OpenIdWebRingSsoProvider into my MVC Project and was having a hard time with the controls "<openid:ProviderEndpoint" so I went to look into the sample OpenIdProviderMVC and notice that they are quite different. So my questions are:

1) What should I use as starting point for my OpenIdWebRingSsoProviderMVC? OpenIdWebRingSsoProvider OR OpenIdProviderMVC?

2) Why both samples (OpenIdProviderMVC and OpenIdProviderWebForms)  seems to be quite different? One uses "IAuthenticationRequest" while the other just "IRequest". What are the differences other than one is implemented in MVC and the other WebForms?

3) Has anyone already implemented a OpenIdWebRingSsoProviderMVC? Sample code?

Thanks a lot!

[Andrew Arnott]

On Thursday, May 3, 2012, Joao Leme wrote:

Trying to implement OpenIdWebRingSsoProvider into my MVC Project and was having a hard time with the controls "<openid:ProviderEndpoint" so I went to look into the sample OpenIdProviderMVC and notice that they are quite different. So my questions are:

1) What should I use as starting point for my OpenIdWebRingSsoProviderMVC? OpenIdWebRingSsoProvider OR OpenIdProviderMVC?

Neither, IMO.  These are just samples.  You should build your own, drawing on the samples for understand of how to interact with the library.  Besides, if MVC is ultimately what you're going to use, starting from scratch will let you target MVC 3 or 4, whereas the sample targets MVC 2.  

 

2) Why both samples (OpenIdProviderMVC and OpenIdProviderWebForms)  seems to be quite different? One uses "IAuthenticationRequest" while the other just "IRequest". What are the differences other than one is implemented in MVC and the other WebForms?

Probably because web forms based Providers can leverage asp.net controls that aren't available (well, aren't "kosure" anyway) in MVC.  I suggest you lean more heavily on the MVC sample in this case.

 

3) Has anyone already implemented a OpenIdWebRingSsoProviderMVC? Sample code?

Not that I'm aware of.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Joao Leme]

Thanks!

The provider seems to be working but I'm getting a AuthenticationStatus.Failed "Error occurred while sending a direct message or getting the response. " when using OpenIdRelyingPartyMVC.

Using firebug I got the following response back from the provider:

http://localhost:54347/User/Authenticate?ReturnUrl=Index&dnoa.userSuppliedIdentifier=http://localhost:54750/openid&openid.claimed_id=http://localhost:54750/user/joaocar...@hotmail.com&openid.identity=http://localhost:54750/user/joaocar...@hotmail.com&openid.sig=lz2xCUoGU514WKsDZOcgpFkFZ0+pYUFptL47PEc9z0g=&openid.signed=claimed_id,identity,assoc_handle,op_endpoint,return_to,response_nonce&openid.assoc_handle={634716722748186307}{/eOS4w==}{32}&openid.invalidate_handle={634716715529016285}{C0ovzw==}{32}&openid.op_endpoint=http://localhost:54750/openid/provider&openid.return_to=http://localhost:54347/User/Authenticate?ReturnUrl=Index&dnoa.userSuppliedIdentifier=http%3A%2F%2Flocalhost%3A54750%2Fopenid&openid.response_nonce=2012-05-03T20:12:06ZpvSIJeRb&openid.mode=id_res&openid.ns=http://specs.openid.net/auth/2.0

The difference from the MVCProvider sample is that I'm using AspNetSqlMembershipProvider instead of the AspNetReadOnlyXmlMembershipProvider and I didn't implement the anonymous identifier provider.

Any idea why the status.failed?

Thanks!

[Joao Leme]

After having a hard time trying to debug and figuring out why the relying party was rejecting the request (guess I'm not a good programmer) got an idea of implementing a simple SSO solution since all sites share (have access) the same database.

Would like your opinion on the approach:

- Trusted site (relying party in white list) make request (redirect) to main site (provider) with a return url.

- Main site log user (if not logged), mark user as logged in database and add temporary token to user database.

- Main site return (redirect) to RP with token.

- RP look into database using token, logs user and deletes token.

DONE! :)

SSOff also easy: just check on every request into user database into bool record (userLogged). NO REDIRECTS. On logout simply change record (userLogged) to false and every site will know.

Hope there are no security flaws?

Green light? Is it a go?

Thanks a lot,

[Andrew Arnott]

It's a new idea, to be sure.  So that alone makes me wary of it since the security implications probably aren't thoroughly understood.

You should find that enabling logging will be a great help in understanding why failures occur.

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/ZPqWkfAtHKsJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.