OAuth does not support the concept of a 'Universal Logout'. Logging out of one application does not log you out of another, as that would not be the desired behavior.
For example, if a Facebook user were to log out of Facebook, it should not log them out of Spotify (if they were using Facebook OAuth).
I have been hired to create a service that acts as a sub-application to transparently embed itself in the workflow of an older monolithic web application. For example, there is a link to the sub-application from the monolith, and clicking that link transparently moves you into the sub application. The sub-application also links back to the monolith, which transparently leads back. The user is able to weave back and forth between the monolith and the sub-application.
The sub-application currently uses OAuth 2.0 to authenticate through the monolith. From the user's perspective, this is mostly a transparent exchange.
To the user, the two application workflows should weave together as one. Given this, the concept of a 'Universal Logout' is desirable. What appears to be a single application to the user should not have some of the pages logged out and other pages logged in.
I currently have a 'Universal Logout' implemented, but I have a feeling that since this is not a part of OAuth, maybe it means this problem should be tackled in a different way.
Given this scenario, is there an alternative to implementing 'Universal Logout' in OAuth? Should OAuth even be used? If not, what should be done? How could this be better architectured?
OAuth 2.0 itself is not a protocol that logs on users to applications (http://oauth.net/articles/authentication/); some (like Facebook) have built a custom extension of OAuth 2.0 to do that; those providers would have to start supporting a custom Single Logout mechanism as well in order to address the problem you mentioned.
There is however a standardized extension of OAuth 2.0 that logs on users to applications called OpenID Connect (http://openid.net/specs/openid-connect-core-1_0.html). That has an extension called Session Management (https://openid.net/specs/openid-connect-session-1_0.html) that allows for the functionality that you describe in a standardized way.
Related
I have one main Asp.net MVC application, I also have a help site and quite a few internal apps (that I need to build - reporting, stats, support tickets).
Question: Can OAuth be used in this way? i.e. a user can be authenticated to use all apps (if they have access to that app)?
Ideally all or most of the other apps will be implemented in Ruby or Node.js - so I am hoping I can achieve this with OAuth.
As long as all of your apps run under the same top level domain, it should not be strictly neccessary to use OAuth or similar to obtain a shared session. Instead you could rely on a plain session cookie. You could run some kind of middleware in between your app and the user.
Only if the main app is providing a REST API that you may want to use on various client apps, where some of them run in external environments / domains, making use of OAuth may be relevant.
My understanding of OpenID is that it provides a way to have one site contain all your identity & peripheral info, but to let other OpenID-compliant (and user-trusted) sites re-use that info for identifying and authenticating the user. Essentially it minimizes the number of logins credentials (usernames & passwords) a user has for the internet.
My understanding of OpenSSO is that it allows you to sign-in to one site and automatically log-in to all other sites that the first site trusts. Essentially it minimizes the number of times a user has to log in to these different sites.
My understanding of OAuth is that it allows users to grant 3rd party sites certain access to their information located at one particular site. Essentially, like OpenSSO, it minimizes the number of times a user has to log in to these different sites. The different with OpenSSO is that OpenSSO logs the user into all the participating sites at once (with full privileges turned on), whereas OAuth grants finer-grained access to these participating sites.
So, first off, if anything I have said is incorrect, please begin by correcting me!
Assuming I am more or less correct, then I have the following questions/need clarification on the following items:
When would I choose OpenSSO over OAuth - just when I want to restrict access that the other participating sites have when a user logs in to one of them?
Are their different security risks for each of these technologies that I will have to consider and integrate into my app - or are they considered secure in and of themselves (basically can I rest assured that if my app uses them that my app is not open to any new attacks)?
Since these technologies are so closely related its hard for me to see the whole "forest through the trees" here - thanks in advance!
Not really the right comparison to be making. OpenID & OAuth are protocols, OpenSSO (now OpenAM) is an implementation of those and other protocols (SAML, OAuth, etc)
Generally speaking, the protocols for OpenID and OAuth are similar even though they originated with different use cases in mind. Today there is a lot of convergence around OAuth 2.0 for both federation (authentication) and authorization cases. The next generation of OpenID called OpenID Connect is built on top of OAuth 2.0 and precursors to this are already in place at Google, Facebook, Twitter, etc...
As for security, there are always some risks, particularly with implementation errors. Pick a good implementation and read the specs so you understand what the risks and countermeasures are.
OpenSSO is for you to log into one site and be logged into multiple sites.
OAuth lets one site extract your data from a second site (pull your tweets or facebook statuses) without the first site having to know how to log into the second site.
I am reading the Service Oriented Design with Ruby book by Paul Dix and many posts here but am left with many questions surrounding authenticating users and the application.
I want to have api.site.com as a RESTful Rails app serving up JSON. Secure.site.com will be a web app (maybe Rails or maybe PHP) that will consume the service. Also a mobile app such as iPad will also consume it.
So is the first step to build in a level of auth so that only my web app and mobile app can consume the service? Then once the calling app has been authenticated, both these apps will have users who want to CRUD their data so then authenticate them as well?
I've read about Http basic, digest, tokens, oauth and many plugins but am having a difficult time narrowing down the most flexible and reusable way. For now this is simply learning so I would like to stay away from plugins so I can learn the code better.
Can my web app use normal sessions like I'm familiar with and then the mobile use their equivalent to sessions. At that point I still have no authenticated the calling app though. Http basic seemed like I could use it from both, but I didn't see a way for my web app to use a normal login form and logging out seemed like an issue.
I would suggest two solutions for you.
Use a Gem like devise for login system and inherit the devise registration and sessions controller to make it respond to JSON requests.
Create your own simple authentication and use respond to HTML and respond to JSON for separating web and mobile login
Iam not totally sure whether a mobile device maintains a session (please look around) but u can always use a token authentication system if it doesnt.
I'm designing a new web application. Some quick points on it:
ASP.NET MVC Web Application
SQL Server 2008
Entity Framework ORM
3 User Roles: Anonymous, Registered, Administrators.
Anonymous users can view stuff, Registered Users can post stuff, Admins can do anything
Heavy social integration with Facebook, Twitter and the like.
I plan to use OpenId for authentication (DotNetOpenAuth)
So, pretty simple right? (famous last words)
Now my question is:
Should i provide OpenId as the only means of authentication, or should i
also give the user the option to log
in using my own authentication system?
So this is basically a "User Experience" question. Take the example of StackOverflow - you MUST signup with OpenId. It seemed fine to me, but what about the general public? Can i be happy with the fact that a user of my site must have an OpenId account? (or signup for one before using my site)
Is giving the user two options to login bad UX?
I realize this is a partially subjective question, but im just looking for advice on which road to take, some case studies would be helpful.
Thanks.
Any good answer to a subjective question begins with it depends. :-)
I think if your prospective user base is already fairly social-network engaged (as it sounds by your description), it will probably be just fine to have authentication handled by OpenId providers. The important part is providing an easy-to-use login process, and make it obvious that various providers are available for authentication (Yahoo, Google, etc.).
If your prospective user base is going to consist of new or inexperienced Internet users, even a simple OpenId implementation may be too confusing.
I, for one, find it annoying to have to create yet another account every time a visit a new website, and I suspect that more and more users are feeling the same way.
There's a decent set of responses to a similar question at https://ux.stackexchange.com/questions/78
The thing is that only OpenID won't cut it in you case mainly because of Facebook and Twitter who aren't OpenID providers. Both use OAuth 2 for authetication. Wikipedia says this about it:
OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
and this:
OAuth is a service that is complementary to, but distinct from, OpenID.
The DotNetOpenAuth also supports OAuth and the latest CTP release implements the OAuth 2 draft 10. Mind you that the OAuth 2 specification is still being developed and is expected to be finalized by the end of 2010. OAuth 2 also isn't backward compatible with OAuth 1.
Are there any decent examples of the following available:
Looking through the WIF SDK, there are examples of using WIF in conjunction with ASP.NET using the WSFederationAuthenticationModule (FAM) to redirect to an ASP.NET site thin skin on top of a Security Token Service (STS) that user uses to authenticate (via supplying a username and password).
If I understand WIF and claims-based access correctly, I would like my application to provide its own login screen where users provide their username and password and let this delegate to an STS for authentication, sending the login details to an endpoint via a security standard (WS-*), and expecting a SAML token to be returned. Ideally, the SessionAuthenticationModule would work as per the examples using FAM in conjunction with SessionAuthenticationModule i.e. be responsible for reconstructing the IClaimsPrincipal from the session security chunked cookie and redirecting to my application login page when the security session expires.
Is what I describe possible using FAM and SessionAuthenticationModule with appropriate web.config settings, or do I need to think about writing a HttpModule myself to handle this? Alternatively, is redirecting to a thin web site STS where users log in the de facto approach in a passive requestor scenario?
An example of WIF + MVC is available in this chapter of the "Claims Identity Guide":
http://msdn.microsoft.com/en-us/library/ff359105.aspx
I do suggest reading the first couple chapters to understand all underlying principles. This blog post covers the specifics of MVC + WIF:
Link
Controlling the login experience is perfectly fine. You should just deploy your own STS (in your domain, with your look & feel, etc). Your apps would simply rely on it for AuthN (that's why a app is usually called a "relying party").
The advantage of the architecture is that authN is delegated to 1 component (the STS) and not spread out throughout many apps. But the other (huge) advantage is that you can enable more sophisticated scenarios very easily. For example you can now federate with other organization's identity providers.
Hope it helps
Eugenio
#RisingStar:
The token (containing the claims) can be optionally encrypted (otherwise they will be in clear text). That's why SSL is always recommended for interactions between the browser and the STS.
Notice that even though they are in clear text, tampering is not possible because the token is digitally signed.
That's an interesting question you've asked. I know that for whatever reason, Microsoft put out this "Windows Identity Foundation" framework without much documentation. I know this because I've been tasked with figuring out how to use it with a new project and integrating it with existing infrastructure. I've been searching the web for months looking for good information.
I've taken a somewhat different angle to solving the problem you describe.
I took an existing log-on application and integrated Microsoft's WIF plumbing into it. By that, I mean that I have an application where a user logs in. The log-on application submits the credentials supplied by the user to another server which returns the users identity (or indicates log-on failure).
Looking at some of Microsoft's examples, I see that they do the following:
Construct a SignInRequestMessage from a querystring (generated by a relying party application), construct a security token service from a custom class, and finally call FederatedSecurityTokenServiceOperations.ProcessSignInresponse with the current httpcontext.response. Unfortunately, I can't really explain it well here; you really need to look at the code samples.
Some of my code is very similar to the code sample. Where you're going to be interested in implementing a lot of your own logic is in the GetOutputClaimsIdentity. This is the function that constructs the claims-identity that describes the logged-in user.
Now, here's what I think you're really interested in knowing. This is what Microsoft doesn't tell you in their documentation, AFAIK.
Once the user logs in, they are redirected back to the relying party application. Regardless of how the log-on application works, the WIF classes will send a response to the user's browser that contains a "hidden" HTML input that contains the token signing certificate and the user's claims. (The claims will be in clear text). At the end of this response is a redirect to your relying-party website. I only know about this action because I captured it with "Fiddler"
Once back at the relying party web site, the WIF classes will handle the response (before any of your code is run). The certificate will be validated. By default, if you've set up your relying party web site with FedUtil.exe (by clicking "Add STS Reference in your relying party application from Visual Studio), Microsoft's class will verify the certificate thumbprint.
Finally, the WIF framework sets cookies in the user's browser (In my experience, the cookie names start out with "FedAuth") that contain the users claims. The cookies are not human readable.
Once that happens, you may optionally perform operations on the user's claims within the relying party website using the ClaimsAuthenticationClass. This is where your code is running again.
I know this is different from what you describe, but I have this setup working. I hope this helps!
ps. Please check out the other questions I've asked about Windows Identity Foundation.
UPDATE: To answer question in comment below:
One thing that I left out is that redirection to the STS log-on application happens by way of a redirect with a query-string containing the URL of the application the user is logging in to. This redirect happens automatically the first time a user tries to access a page that requires authentication. Alternatively, I believe that you could do the redirect manually with the WSFederationAuthentication module.
I've never tried to do this, but if you want to use a log-on page within the application itself, I believe the framework should allow you to use the following:
1) Encapsulate your STS code within a library.
2) Reference the library from your application.
3) Create a log-on page within your application. Make sure that such page does not require authentication.
4) Set the issuer property of the wsFederation element within the Microsoft.IdentityModel section of your web.config to the login page.
What you want to do is an active signin. WIF includes WSTrustChannel(Factory) which allows you to communicate directly with the STS and obtain a security token. If you want your login form to work this way, you can follow the "WSTrustChannel" sample from the WIF 4.0 SDK. Once you have obtained the token, the following code will take that token and call the WIF handler to create a session token and set the appropriate cookie:
public void EstablishAuthSession(GenericXmlSecurityToken genericToken)
{
var handlers = FederatedAuthentication.ServiceConfiguration.SecurityTokenHandlers;
var token = handlers.ReadToken(new XmlTextReader(
new StringReader(genericToken.TokenXml.OuterXml)));
var identity = handlers.ValidateToken(token).First();
// create session token
var sessionToken = new SessionSecurityToken(
ClaimsPrincipal.CreateFromIdentity(identity));
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
}
Once you have done this, your site ought to behave the same as if passive signing had occurred.
You could use the FederatedPassiveSignIn Control.
Setting your cookie like this:
FederatedAuthentication.SessionAuthenticationModule.WriteSessionTokenToCookie(sessionToken);
Doens't work for SSO to other domains.
To cookie should be set by the STS not at the RP.