I have been implementing a skeleton Claims Based architecture for our services and websites. I'm using WIF, .NET 4.5, MVC / Web Api.
I have the STS (WS-Federation / WS-Trust) and several Relying Parties implemented, and all is working fine.
Now, I want to be able to authenticate in one Relying Party and use that same token (the bootstrap token, I assume) to make Ajax calls to another Relying Party. I can get the Bootstrap Token down in the HTML (is this even a good idea?), and add it to the Ajax call headers as some form of Authentication (Basic, etc).
What I don't know is how to intercept the request in the final Relying party, and "tell" WIF to use that bootstrap token and do it's magic with it (Load, Validate, Authenticate, Authorize, Create Principal, Create Session Token, Write it down in a cooke).
I guess I could do all this by hand using the available classes, but there must be a point where I can just hook up for this. Probably around the SAM / FAM modules, but I can't understand exactly how.
Any ideas?
Thanks
SAML is not a good fit for being consumed in html. The format is complex and relies too much on WS-Security for cryptography. I see more adoption these days of OAuth2 (It was OAuth-Wrap in the past), although is complex as well. If you want to explore that path, I recommend the ThinkTecture Identity Server as a quick solution.
http://weblogs.thinktecture.com/cweyer/2012/11/oauth2-in-thinktecture-identityserver-v2-implicit-grant-flow-with-javascript.html
Thanks
Pablo.
Related
I have 2 projects an mvc5 & webapi. I am wanting to call the api from a pure clientside manor even though im using mvc (I am slowing trying to migrate old code into a spa like application still being able to maintain the current codebase).
The url of the api sits under the main domain e.g. subdomain.mydomain.com/api so I dont have to worry about jsonp or crossdomain stuff.
How do I secure the api. Am I right in thinking when a user logs into the mvc5 application there is there some kind of key or token I can access. I store it somewhere on the site and add it in the request header?
If I follow this approach how do I validate the token at the api end. An actionfilter that reads the header? or is there a cleaner method.
The only information I can really find on using the api is to use basic auth which is something I dont really want to have to do.
I think a nice simple(ish) way to do it is to use a token based method. So the client authenticates once, you give them a token, then subsequent requests pass the token and the server checks it.
It does require some custom code, but I have seen a few good examples. Here is one that I loosely followed:
http://www.codeproject.com/Articles/630986/Cross-Platform-Authentication-With-ASP-NET-Web-API
It enforces HTTPS, then does the token generating and validation after that.
I'm starting a new system creating using .NET MVC - which is a relatively large scale business management platform. There's some indication that we'll open the platform to public once it is released and pass the market test.
We will be using ExtJs for the front-end which leads us to implement most data mining work return in JSON format - this makes me think whether I should learn the OAuth right now and try to embed the OAuth concept right from the beginning?
Basically the platform we want to create will initially fully implemented internally with a widget system; our boss is thinking to learn from Twitter to build just a core database and spread out all different features into other modules that can be integrated into the platform. To secure that in the beginning I proposed intranet implementation which is safer without much authentication required; however they think it will be once-for-all efforts if we can get a good implementation like OAuth into the platform as we start? (We are team of 6 and none of us know much about OAuth in fact!)
I don't know much about OAuth, so if it's worth to implement at the beginning of our system, I'll have to take a look and have my vote next week for OAuth in our meeting. This may effect how we gonna implement the whole web service thing, so may I ask anyone who's done large-scale web service /application before give some thoughts and advice for me?
Thanks.
OAuth 1 is nice if you want to use HTTP connections. If you can simply enforce HTTPS connections for all users, you might want to use OAuth 2, which is hardly more than a shared token between the client and server that's sent for each single request, plus a pre-defined way to get permission from the user via a web interface.
If you have to accept plain HTTP as well, OAuth 1 is really nice. It protects against replay attacks, packet injection or modification, uses a shared secret instead of shared token, etc. It is, however, a bit harder to implement than OAuth 2.
OAuth 2 is mostly about how to exchange username/password combinations for an access token, while OAuth 1 is mostly about how make semi-secure requests to a server over an unencrypted connection. If you don't need any of that, don't use OAuth. In many cases, Basic HTTP Authentication via HTTPS will do just fine.
OAuth is a standard for authentication and authorization. You can read about it in many places and learn; Generally the standard lets a client register in the authentication server, and then whenever this client attempts to access a protected resource, he is directed to the auth-server to get a token (first he gets a code, then he exchanges it with a token). But this is only generally, there are tons of details and options here...
Basically, one needs a good reason to use oAuth. If a simpler authentication mechanism is good for you - go for it.
I am building a REST API using Grails. I want it to be protected using OAuth2.0 client_credentials flow(grant_type). My use-case is as follows:
a external agent will send a request to something like
http://server-url/oauth/token?client_id=clientId&client_secret=clientSecret&grant_type=client_credentials
and obtain a access_token. Then, my URL(protected resource) should be accesible with something like
http://server-url/resource?access_token={access-token obtained before}
I am looking for something that makes doing this on Grails easy and quick. What will be the best way/tool/plugin to use for this ? Scribe library is an option, if there are any tutorials for my specific use-case, it will be great.
P.S.: I have tried the spring-security and related plugins, no joy there. Any alternatives would be nice.
I have the same issue. I found a lot of grails plugins that helped you authenticate your app against other oauth providers, but nothing that would help me make my app the oauth provider. After a lot of digging, I came across this grails plugin that will do exactly what you want.
https://github.com/adaptivecomputing/grails-spring-security-oauth2-provider
I'm still configuring it for my application, and I think the docs might need a few edits (specifically the authorization_code flow) but I got the simple client_credentials flow to work with minimal configuration. Hope that helps!
Based on my experiences, Scribe was built for OAuth 1.0 and has only very limited support for OAuth 2.0. In fact, for testing our own OAuth 2 implementation, all we could use from it was an HTTP request wrapper, we had to do anything else manually. Fortunately, doing it manually is suprisingly easy.
Since I still haven't found a fine open OAuth 2.0 library for Java (frankly I'm not familiar with Groovy), I encourage you to write the client code for yourself. You don't even need a client callback endpoint to use the client credentials grant flow. So you simply create an HTTP request (as you've written above already, take care to escape the GET parameters though) and get the response content. Your flow does not use redirects, so simply parse the JSON object in the response content, e.g. with the org.json library. Finally, send an HTTP request using the extracted access token.
Note that your examples are not completely standard compliant. The standard requires using HTTPS, sending the token in an HTTP header instead of a GET parameter and suggests using a HTTP basic authorization header instead of GET parameters to specify client credentials.
I may have misunderstood your question, and you may want to implement the server side, too. The scribe library supports only client side, so you can find a commercial implementation or implement your own server. It is a complex task, but if you support only the client credentials flow, it almost becomes easy. ;-)
This isn't a plugin, it's just a sample Grails application that acts as an OAuth provider. It was really easy to get up and running with Grails 3.
https://github.com/bobbywarner/grails3-oauth2-api
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH
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.