OpenId Guide

[gsogol]

Does anyone have a guide that can explain how OpenId + oAuth
(specifically DotNetOpenAuth project) work together in a non-spec
manner? Which could possibly describe how it solves various security
holes (replay attacks, XSS, CSRF, etc). Would absolutely love to use
instead of WS-Federation Profile but really need more info in order to
start the process.

Any help is really appreciated.

[Andrew Arnott]

Are you looking for a sample?  There is a sample of the OpenID + OAuth hybrid included with the library.

Replay attacks are mitigated by the library itself.  But CSRF and XSS attacks must be mitigated by the hosting web site, since mitigations for these rely on how the site receives and renders HTML, and Javascript that the site hosts.  The library properly escapes all inputs and unescapes outputs so that no attack at the OpenID or OAuth protocol layers can alter code paths, but the hosting site is responsible for what it does after it comes out of the library.  For instance, if an access token were to have an apostrophe in it, DNOA would have no issue with that.  But if you were to just insert that inline into a SQL statement you'd be vulnerable to a SQL injection attack.  DotNetOpenAuth has limited scope in which to protect you.  Database access, HTML rendering, and CSRF all fall outside the scope of the library and on the shoulders of the web developer.

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

[gsogol]

Cool, thanks for the response. I just downloaded the latest code and
see the samples but I gotta be honest, no clue where to start or what
it does. And no I'm not dumb :). I get the idea of OpenId and oAuth as
in the valet key analogy but I don't know what each sample does.
Besides the samples which I could try to figure out I was more looking
towards how OpenID/oAuth actually work as opposed to the heavy
Microsoft's Geneva stack built on SOAP. I have a RESTful framework
(non-Microsoft) and would love to see how I can incorporate this in
using SSO among our web apps and RESTful services. Kind of like
activity/sequence diagrams or anything at this point. Just want to see
if certain security holes are addressed (besides what you mentioned).
Would also be interested to see if I could create my own OpenID
provider where all the applications only trust my provider and never
some 3rd party. I'm not creating a blogging site and would want to see
if it's possible to use it within the enterprise.

Again, thanks.

[Andrew Arnott]

Ok, I think I understand better where you're coming from.  (by the way, can I get your name -- even a first name?  I like to have a way to refer to you).

I know there are several people (likely quite a few) who have used DotNetOpenAuth to achieve an SSO environment in their enterprise such as you've describe, myself included.  Absolutely DNOA can be rigged to only allow a custom list of Providers so you can have your one enterprise sign on page.  

In fact, you can rig the Provider you write with DNOA to just sniff for your corporate network credentials if they are available and avoid the login experience entirely for that scenario.  Then you can write all your Relying Party sites to automatically log the user in using that Provider (either through checkid_immediate via javascript or by redirecting momentarily with checkid_setup) rather than ever displaying the login page where they pick a provider or type an identifier.  The end result of this being that every web site in your enterprise automatically knows who visitors are, and the authentication always occurs at one controlled web site (your one Provider).

In this way OpenID becomes more of a low level protocol rather than an active part of the user experience, which is a perfectly applicable use for it.

One thing to keep in mind is that OpenID focuses on figuring out who the user is, whereas OAuth is about allowing one (web or desktop) application to access private user data within a different application while impersonating that user.  Each has its purposes by themselves, and the hybrid of the two is interesting when you're authenticating the user and you already know that the same entity that is authenticating the user also has private data on that user that you'll want to programmatically access after authentication is completed.  And of course DNOA supports all of those scenarios.

DNOA doesn't come with a prebuilt "OpenID+OAuth for the enterprise" kit, partly because every enterprise will have different requirements for integrating the library.  

One relevant OpenID+OAuth sample that ships with the library is the OpenIdRelyingPartyWebForms' loginPlusOAuth.aspx page.

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

[gsogol]

Thanks Andrew. Well, my name is Jeff.

So I'm trying to re-read what you said regarding checkid_* but I'm
struggling but I'll get there eventually. What I would recommend
assuming you desire to steal people from enterprises instead of just
social sites is to actually have the sample you mentioned. In reality,
most enterprises or companies I've been at, follow a very similar
design. No offense, but most enterprises shy away from open source
projects and trust the big boys (IBM, Microsoft). That's the nature of
the beast. Whether it's SiteMinder or Msft Geneva, they are all based
on the same principal, how does one secure web apps and services
within the enterprise.

Now, the sample that is most commonly used is that whole Alice and Bob
sample as can be seen here (http://download.microsoft.com/download/7/d/
0/7d0b5166-6a8a-418a-addd-95ee9b046994/
GenevaFrameworkWhitepaperForDevelopers.pdf) [page 7, Basic Scenario].

If you start showing to enterprises that look the same can be achieved
via OpenId/oAuth then you've got something. Marketing is also
important but I digress. What sways people is showing that the same
thing can be done in a different way (apples-to-apples) and guess
what, it's RESTful.

Anyways, since my original question was all about me and my needs (I
think I sound like my wife now :), what will help is again some clear
introduction what the two standards are and how they resolve SSO. In
terms of modifying the code, I will look through the code and
hopefully I'll understand most of it but again it would help to have
some guide that talks about components and projects unless you feel
I'm the only person who had hard time deciphering through them and in
that case I'll swallow my pride and figure it out.

[Andrew Arnott]

Thanks, Jeff.  I think you're absolutely right.  An Alice & Bob illustration of how it could work in the enterprise would go miles toward greater adoption of OpenID and OAuth.  I'll put it on my list.  My time being constrained by the fact that this is just a side project besides my day job prohibits me from making any commitments as to when such an enterprise ready document and sample will be available.  But I'd like to think within a month or two.

I'm struggling to find the optimal presentation of the many samples (which in fact aren't even enough to demonstrate all the features of the library or the underlying protocols) so that they aren't so confusing.  It seems that there are people on both sides of finding the samples easy or difficult, so I'd like to improve on it where I can.  If you figure it out, please let me know.

And BTW, I do offer private contracting services as well, so if you're interested in some hands-on help (including NDA if necessary) in applying the library to your specific environment we can chat offline about that.

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

[gsogol]

Thanks Andrew. I will note the last part.

In terms of the presentation, I would simply have two web apps and say
one service and you simply want to do SSO across them. I think that's
a very basic scenario. There are enough social samples on the internet
and that was not a problem for me. If I wanted to do a blogging site,
no problem. It's how one would customize it for the enterprise that I
couldn't figure it out.

Could you at least put together a quick diagram that explains the flow?
For example, are tokens checked on every request? Are there cookies
involved? When someone redirects to another site, do you have to do
something special? Add any url parameters, set form fields, cookies?

[gsogol]

Andrew, so the OpenId 2.0 spec (http://openid.net/specs/openid-
authentication-2_0.html), section 11.3 talks about checking for nonces
for replay attacks. Where are the nonces stored in your library?
Wanted to see how distributed that is and how that works in a farm.

[Andrew Arnott]

A similar question has been asked on StackOverflow.

By default, DNOA stores nonces in memory on one server only.  But for farm environments, you can either go stateless (and rely on the Provider to comply with the OpenID spec for replay protection) or for maximum performance and security you can implement IRelyingPartyApplicationStore, which allows you to control how nonces and associations are stored so that they can be shared across all the servers on your farm.

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

[gsogol]

Cool, so I'm assuming you have your own IRelyingPartyApplicationStore
implementation but one can create their own and possibly use
distributed cache? If so, do you have to register it somewhere?

[John Bradley]

Several of the Large OP don't check nonces in stateless mode, so I don't recommend doing that.

I know one site using dotNetOpenAuth in a cluster as Andrew described.

There are also potential issues with SSL load balancers that need to be considered.

Clustering can be supported with dotNetOpenAuth.  Other libs are more problematic.

John B.

[gsogol]

I'm dealing with extremely sensitive data so it's not an option for me
not having nonce checks. Plus, since it's part of the spec, it really
should be implemented. Man-in-the-middle and replay attacks is my
primary concern so I have to implement checking for nonces on every
request. I can use memCacheD/Velocity and simply expire them after the
token expires.

I'm failing to understand what SSL balancers have to do with nonces.
SSL can be enabled in any manner but the attacker can simply replay
the RPC packets. If you have, I'd love to read more about it.

Also, if by clustering you mean a failover system, then it's really
not a concern, I was worried more about load balanced web servers.

[Andrew Arnott]

Yes, DNOA comes with its own implementation.  That's the one that just uses one server's own memory -- not good for farm environments.

After implementing the interface, you can either instantiate it yourself and pass it to the OpenIdRelyingParty constructor, or you can register it in your web.config file.  Here's a relevant snippet of the config file, but you can see it in context here.

	<dotNetOpenAuth>
		<openid>
			<relyingParty>
				<store type="Fully.Qualified.ClassName, Assembly" />
			</relyingParty>

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

[Andrew Arnott]

I've helped probably a dozen people use DNOA in a web farm environment.  I've never heard a complaint. :)

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

[John Bradley]

You should look at:

ICAM OpenID 2.0 Profile

If you are concerned about security as a RP.

If the load balancers terminate the SSL sessions, there are some adjustments you need to make so that the lib can verify that the connection was over SSL.

That was one issue we had to sort out in a large US Gov RP.

So there were the two issues that came up in deploying the lib in a cluster.

Both were sorted out relatively easily.

I should say that at best you get LoA 1 from openID if the OP supports it.

If your data is that sensitive think carefully.

Consider the OMB-04-04 guidelines.

http://www.whitehouse.gov/OMB/memoranda/fy04/m04-04.pdf

John B.

[Andrew Arnott]

Good points, John.

 

The ICAM OpenID 2.0 Profile itself may be overkill for you if your RP doesn't require the strict PPID-like privacy rules that the U.S. government requires, and don't want to restrict your users to use gov't approved OPs. 

 

Other options include turning on RequireSsl mode in the library, or any of the other optional security switches you can flip on.

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

[gsogol]

Thanks John and Andrew for some pointers. I've read the ICAM doc and I
think Andrew is right, it may be an overkill for me. Out of curiosity
is it supported in the library? If not, did John create his own
extenion?

May be for now I just implement the interface and add my own
distributed cache for storing nonces. Andrew, how do you receive the
nonce? Does the interface have some method with a nonce as parameter?

[Andrew Arnott]

Inline....

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

On Fri, Sep 25, 2009 at 11:25 AM, gsogol <gso...@gmail.com> wrote:

Thanks John and Andrew for some pointers. I've read the ICAM doc and I
think Andrew is right, it may be an overkill for me. Out of curiosity
is it supported in the library?

Yes it is.  

 

If not, did John create his own
extenion?

May be for now I just implement the interface and add my own
distributed cache for storing nonces. Andrew, how do you receive the
nonce? Does the interface have some method with a nonce as parameter?

Yes. And there's a sample IRelyingPartyApplicationStore implementation included with the library, although there was a bug in the sample that was only recently fixed.  So here's the corrected sample.

[gsogol]

Thanks.

1. What do other methods (besides StoreNonce) do and when do they get
executed in user lifecycle?
2. Andrew, you mentioned a few weeks back about rigging DNOA and using
checkid_immediate with javascript to redirect to my one provider or
checkid_setup? Can you point me in DNOA where I would need to modify
or this?

[Andrew Arnott]

Inline...

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

On Fri, Sep 25, 2009 at 11:45 AM, gsogol <gso...@gmail.com> wrote:

Thanks.

1. What do other methods (besides StoreNonce) do and when do they get
executed in user lifecycle?

You can find the documentation for these methods here. 

2. Andrew, you mentioned a few weeks back about rigging DNOA and using
checkid_immediate with javascript to redirect to my one provider or
checkid_setup? Can you point me in DNOA where I would need to modify
or this?

DNOA itself doesn't need to be modified.  It's just how you use it.  You can create a checkid_immediate request using the standard OpenIdRelyingParty class.  Although checkid_setup (the default mode) may work just fine for you as well.  You just make every relying party site's login page immediately redirect the user through your choice of a Provider (instead of asking the user for their identifier) and when the positive response comes back, log the user into the RP.  It's just like any sample RP's login page, except that instead of asking the user for the identifier you force your own OP Identifier.  

Then you write your OP.  If the OP implicitly knows who the user is through some passed through network credential, then it could immediately respond with a positive response without even prompting the user, giving the user the impression of a SSO experience across all web sites.  Or, it could maintain a list of white-listed RP realms that are your internal network of sites and only work with them, or only work without prompting the user for those, etc.  Lots of options for you here.  

[gsogol]

Ok, tnx. This will probably happen in the next phase of my project but
thank you for some pointers. If you ever get an example going at some
point, it will help as well. But thank you either way.

[gsogol]

I'm assuming DNOA creates a cookie for SSO among multiple apps within
a domain so that's fine.

1. Correct me if I'm wrong.

2. Once you're in some web app and need to make multiple web service
calls who also need to be secured, how will it work? Say I need to
asynchronously call 2 distinct web services and each service checks
whether or not the user has rights to call its operation. Can you walk
through that scenario?

[Andrew Arnott]

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

On Tue, Sep 29, 2009 at 9:11 AM, gsogol <gso...@gmail.com> wrote:

I'm assuming DNOA creates a cookie for SSO among multiple apps within
a domain so that's fine.

1. Correct me if I'm wrong.

DNOA creates no cookies at any time.  At the RP side, it merely indicates to the hosting web site whether a positive assertion has a valid signature, and who signed the assertion.  It's up to the RP host site to decide whether that assertion comes from a trusted party, figure out what user account the OpenID Claimed Identifier is associated with, and to store cookies as appropriate.  ASP.NET implicitly sets a cookie when you call FormsAuthentication.RedirectFromLoginPage (or SetAuthCookie, I believe it's called).  But that's not DNOA itself, and is totally under your control.

 

2. Once you're in some web app and need to make multiple web service
calls who also need to be secured, how will it work? Say I need to
asynchronously call 2 distinct web services and each service checks
whether or not the user has rights to call its operation. Can you walk
through that scenario?

 

I think what you're talking about is that Bob visits some web site RP, and for RP to function it needs to send requests to other servers on Bob's behalf.  How do those remote servers validate that Bob is the integator of those requests?  DNOA doesn't mandate a way, but it provides one.  The simplest possibility is that these servers trust RP, and RP just declares who the user is that it is operating on behalf of.  Simplest, but if that implicit trust isn't available (and there are plenty of valid reasons for that) another option is OAuth, which DNOA also facilitates.  OAuth and OpenID are orthogonal to each other (either one works without the other, or with the other -- they don't know or care).  OAuth helps the user authorize RP (the "consumer" in OAuth terminology) to access protected data on the remote servers (the "service provider") and provides a way for the service provider to verify that the message was indeed sent from the consumer, with the user's authorization.

[gsogol]

Ok, so in point #1, once the user is in, how does each request
checked? What makes the user authenticated from the browser/http
perspective? You said, FormsAuthentication.RedirectFromLoginPage sets
the cookie but if that is not called and the cookies is not set, then
what?

Point #2, what and how is something actually passed in to the service?
is it a token? via the header? I'm having trouble when someone says
"oh, it's up to you how you want to do things". OpenId and oAuth are
both specs so they both should say this is how you secure X and this
is how you delegate. With WS-Federation and SAML, it's pretty clear
but I'm not getting OpenId/oAuth in the simplest SSO scenario between
let's say 2 web apps and 2 web services. I feel I'm beationg my head
against the wall and you've been patient but am not connecting the
dots.

[gsogol]

Just to add, I'm looking for something like a sequence of steps with
keyword like token, cookie, header, nonce, etc. Sorry for being
annoying and persistent.

[Steven Livingstone-Perez]

I'll have a stab from my perspective.

1. If you don't set a cookie (of more specifically an authentication ticket)
then nothing will happen. OpenID simply says "this person was authenticated
as this identity as identity provider X". This is the exact same as a custom
database lookup where you need to set the authentication ticket yourself to
say the validation was successful.

2. In the second case you have a local identity prior to calling the
services. This identity *may* have been created via the OpenID method in (1)
above. Calling a remote service is a completely different thing though and
very much platform specific. You *may* use oAuth and request a token (per
the spec here) from the remote server that is locally associated with the
user authenticated in (1) above. This token is the access token for that
user and you should protect use of that based on the authenticated user.

You may also use the trusted server concept to delegate the identity or in
the case of Active Directory you may use Windows impersonation and Kerberos
constrained delegation to make secure service calls - many other ways too.

steven
http://livz.org

--------------------------------------------------
From: "gsogol" <gso...@gmail.com>
Sent: Tuesday, September 29, 2009 6:00 PM
To: "dotnetopenid" <dotnet...@googlegroups.com>
Subject: [dotnetopenid] Re: OpenId Guide

[Andrew Arnott]

That's right, Steven.  If you expect to keep the user logged in for more than a single positive assertion request (and it's pretty useless otherwise) you have to set a cookie, or use another method, such as ASP.NET cookieless session that manipulate the URL path to embed a unique string in that.

 

Now about your OpenID+OAuth connect-the-dots request: I definitely appreciate the frustration you may be feeling and you desire to have someone lay it out from beginning to end.  Here's the problem with that as I see it.  This (and I'd venture to guess most) mailing lists where OpenID and OAuth are discussed tend to be excellent at two things: answering general questions, and responding to very specific questions/problems where the asker has already begun implementation and has hit some snag. 

But these same public mailing lists on open source projects are not so good at giving you an end-to-end solution to a specific company's infrastructural or organization requirements.  It's not at all that we don't care about it, please don't misunderstand, because we absolutely do care, recognize these people as very important technology adopters and want them to succeed.  The problem with answering your "how will this work end to end?" question is the same problem that prevents us from shipping end-to-end samples: every individual organization will have their own unique requirements that will make those dots that we connect for you wrong in one way or another for that organization.  In the end, someone has to have a grasp of your individual organization's requirements and a good grasp of the technologies that can fill those requirements in order to patch them all together in a useful way. 

 

While I'm confident that DotNetOpenAuth can fit the bill at least insofar as I've understood it by your emails, providing an accurate connect-the-dots story of how it would all fit together requires that I have much more knowledge about your network topology, security, platforms, etc.  And because it quickly becomes so involved, it falls outside the scope of what I (and I imagine many others) would consider "free support". :)  This is an open source project and I like to devote my time to improving the project.  If I spend significant time helping an individual implement a custom solution, that's time that I or others will charge for since it's services provided specifically to your organization.

 

So that's a long-winded way of saying: if you're interested in going down that road with me, contact me off the mailing list and we can work out a private consulting agreement.

 

But of course others on this mailing list may feel differently, and perhaps you can get the information you need from them over this list.

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

[gsogol]

Ok, well thanks for being blunt :). I just feel like what I'm asking
is also very common. Most, probably have one site in need of security,
but my scenario and I can't be the only one is as common. Most folks
probably abandon the idea of SSO with DNOA beacuse it's not documented
anywhere where I, on the other hand, was persistent and they simply go
the WS-Federation route because it is documented and it's clear how it
can be used. Now, I know, it's open source and I shouldn't demand
anything. I get all of that. My hope was simply to understand it and
somehow actually document it so it's understood by folks who do want
to implement multi-site single-sign-on security. That's all my
scenario really is...multi-site SSO. It has nothing to do with being a
corporate scenario or something completely out of the ordinary. Simply
a multi-site scenario that possibly uses background services and how
one secures it via DNOA. It's as generic as that.

But at a minimum, thank you for taking the time to respond.

[gsogol]

Also, thank you Steven.

[Praveen Raj]

I am a developer in .Net . I have few websites couple of them developed in .Net and one in Rails on Ruby. I downloaded the samples for DotNetOpenAuth looking at the samples for ringSSOProvider and ringSSORelyingParty.. 

Question 1: can this be used for Rails on Ruby as well?

Question 2: I dont understand the sample which has like 33 projects in it.. Do we have any documentation to guide me.

On Wednesday, September 2, 2009 12:02:17 PM UTC-4, gsogol wrote:

Does anyone have a guide that can explain how OpenId + oAuth
(specifically DotNetOpenAuth project) work together in a non-spec
manner? Which could possibly describe how it solves various security
holes (replay attacks, XSS, CSRF, etc). Would absolutely love to use
instead of WS-Federation Profile but really need more info in order to
start the process.

Any help is really appreciated.