I have been asked to implement integration with a SAML 2.0 IdP for user Authentication purposes. I have never worked with any federated authorization processes so this is all new to me so please forgive if I am asking a stupid question but here it goes.
For My needs all I want is to send a SAMLP Authentication request. If I get a response that says the user is valid I will give them access to my system which will have a user id that matches what is returned. From that point on all authorization is to be performed by my system and I do not need to send a token with each request to the SAML IdP. After they log in I am done with the IdP.
Many of the questions and examples I see on here and other sites include adding extensive libraries to my project. When I look at them and the documentation around them they all seem to want to either perform the authentication with every request through an IIS Module or through integration with the MVC routing mechanism.
So now to my question. Can't I just create the XML myself and stick it on the the querystring as the SAMLRequest value? Then parse the response XML that comes back for the values I need? If this is a valid way of doing it does anyone have some example code that does this?
Any help would be greatly appreciated
The flow that you describe is how things are normally done: One SAML2 request to the Idp to authenticate the user, and then setting a session cookie for all subsequent requests.
Don't create this yourself unless you want to investigate substantial time to understand SAML2 and XML signature validation rules. They are complex and most custom implementations get it wrong, resulting in compromised security.
My own library, Kentor.AuthServices works the way you want. Even though it comes either as an httpmodule, an mvc controller or an owin middleware, it only interfers with the first requests that make up the actual sign in. All subsequent requests are just passed through and the session cookie mechanism handles the session authentication.
Related
I am quiet confused about how to find the technical solution of my business need. I just want to be able to give third party web apps a temporary URL to a specific user so he can access his account without log in.
I have though about a certificate that I use for every external portal. So When I get a request from them with a specific address I send them a redirect URL that is available for 5 minutes.
My application is build over .NET MVC.
Could somebody help me find out how to implement this need ?
You could generate a token and set an expiry date and send the token as query parameter and create an authorization attribute class to check if you have the token and it is valid or any other authorization you have.
You have many ways to do it but you can begin with Basic Authentication which I ended up implementing. I advice you to read the whole tutorial, any misleading could end you up to a non working code with lots of headaches.
If you need more powerful security you can go for Certificate Authentication where you have to provide your clients with client certificates.
These link1, link2, could be useful too if you don't have experience dealing with certificate generation and implementation.
I looked everywhere for an answer about securing my webApi but always i'm pointed to OAuth or openID, but i don't want the user to login or authenticate. This is my problem:
I have a webapi which is called via Javascript to get the data in Json. This data is used in the Html of that page. (deployed on Azure)
Now i don't want someone else to get that data via Javascript or with a simple GET request. Only my html page is allowed to do so.
I'm looking for something to secure my Webapi to be only consumed by the applications i want. If i look to the OAuth and Azure stuff, people always have to login, but i want this page to be public, but only the webapi needs to be secure.
I can't check on IP, because the call is done at client side in the browser.
It is not possible to authenticate and thus secure the API to be used by a specific client (run entirely in the browser - like SPAs) app. You cannot protect the data the app sends to the API. (see for more details Protecting REST API behind SPA against data thiefs)
You could build some modules server side and then use some token based server to server communication if you do not want to introduce users and end user authentication.
Of course it is also a question of how you interpret security.
If it is just that you do not want other web apps to use the data -
CORS policies will do the job. It is unlikely that there will be more
than some isolated cases of users using a browser other than the
popular once which respect CORS.
If it is you do not want data to be mass downloaded you could
implement some client filtering based on IP. This could even be done
on the networking layer so the API do not need to be modified in any
way.
As a suggestion, you can have it secured making sure the request has some headers defined by you. For example, you can set an Authorization header with a token that only you know. You can for example, create a token based on a key that you and the webapi share, encrypt it with the time you are calling the api. The web api receives the request and:
1 - Check if the request has the token it requires;
2 - if it does, it creates a token the same way your page did;
3 - matches its token with the requests token;
If you are calling the webapi via javascript, the method may be exposed. However, it's one idea
Take a look to CORS (Cross Origin Resource Sharing), it may be your solution.
In synthesis you can allow requests to the Api only from some specific websites. Most, nearly all browsers, support it.
This is how you enable and configure it in Web Api 2.
I have an ASP MVC4 web site. Originally, most of the content was served via controllers as one would expect. I have moved the data storage from SQL Server to MongoDB. I have also added a lot of ajax to update data client side, without a full refresh. This is working fine, but my controllers now have lots of methods that take json and return json. I was able to build a Node.js server that hits the database and exposes exactly the same functionality, without lots of going to and from C#.
My javascript client-side is now calling a Node.js REST API, this works great. My 'secure' code (like adding a new user) hits the same REST API from the server side.
My question is this: How can I handle security properly with this? I have three scenarios:
GET api/messages: No need for security, I want to expose my site's messages to anyone who is interested via a Json REST API.
GET api/my/messages: I need to allow access to this only if the user is logged in (it gets the user's messages).
POST api/users: This is a function that should only be called from the server, and nothing else should be able to use it.
As the user is already logging in to my ASP website, how can I use their logged in credentials to authenticate them with my REST service? While the user is logged in, the pages client side will hit it regularly for updates.
Is there any sensible/standard way to do this? The core idea is that the client side code uses a REST API that is at least partially open to the public, and that in fact that API offers all of my business logic - only parts of it (like creating a user) are locked down to super-admins only.
Thanks in advance!
Create two authentication middleware handlers. One you add to all your "my" routes and another which you add to your POST routes.
The "my" authenticator takes the asp.net auth cookie that is present in the request and makes a http call to your asp.net mvc site with it.
You'll need an action which either returns a 401 if the cookie is invalid otherwise it returns some info about that user's permissions perhaps.
If the request into node doesn't have a cookie, return a 401 again.
In addition, to prevent excessive calls to your mvc site to check the cookie, you could use the cookiesession middleware to set a cookie on the client with a flag of authenticated. That will result in 2 cookies for your client, but that shouldn't be an issue. Just make the node one expire before the aspx one.
The POST authenticator middleware can use any shared secret you like between your node and mvc server. e.g. a special header in the request.
If the user is required to login you can use [Authorize] on your controller actions. Autorization will be handled like any other webrequest.
Furthermore you might consider to add a key to your api requests which you can provide in the initial page load. A autorized user will have a GUID which he will sent with the api call. You can check if this key was issued by your app to a valid user.
As you said all the secure calls already go through your MVC server code which in turn calls the Node.js code, am I right? Basically you need a way to block calls to this Node.js from other clients that are not your MVC code.
Thinking out loud, these are the ideas that pop into my mind:
Use SSL only between MVC and Node. You can set up client and server certificates so that the Node code will only respond after authentication (I don't know how Node handles SSL so you will need some documentation here
If you want, the Node server could also check the call origin and so you can filter based on IP and only allow IPs where your MVC code is sitting
Use an encrypted authentication token on the secure methods on the Node code. Again I'm not really a Node expert but I can imagine it has ways of decrypting a token, or you can simply base it on a random number with a common seed... If noone has access to your server code ideally noone should be able to guess this token. Again, SSL will help against traffic sniffing
I am quite sure that people will come up with other ideas. For me, the most basic thing is anyway ensure that the secure methods are only accessible through an SSL connection and on this connection you can exchange all the info (token, passwords, etc.) you desire.
I need to implement authentication for some web services that we will be hosting. I want to use open standards, so I am interested in OAuth.
I will be using WebAPI for these services.
So here's where I'm running into trouble: Most (or maybe all) of the Api Key/OAuth scenerios that I have read involve (at some point or another) a user sitting in front of a screen.
I need to put together an API that a business partner will be calling. The calls will come from an automated process -- nowhere in the chain will there be a person who can be redirected to a web site with logon credentials.
However, I don't want just anyone coming around and calling my services.
So, I read about OAuth, and how it uses a shared secret to sign each request, and I think that's what I'm after. (I would either set up a session key, or could consider making one of the parameters a "ticks" value, and only accept requests within a short timeframe, etc)
I was kind of hoping that I could use DotNetOpenAuth to accomplish this (or something like it), but every example I come across begins with "the user gets redirected to a login page). I only need "2 leg" authentication.
Is there an example of using DotNetOpenAuth to do this?
Is there a better way to go?
If you are looking at OAuth 2 then the flow you are describing is the Client Credentials Grant
This kind of "two legged" / "service account" type flow is one that doesn't have a web page based flow.
DotNetOpenAuth supports the Client Credentials Grant. You can see an example of it in action here; however, be aware even though the author states it is the "Resource Owner Password Credentials" grant it is actually the Client Credentials Grant.
The blog post above was a little out of step with the latest DotNetOpenAuth code base but these are quickly identified and altered.
I believe that as it stands the DotNetOpenAuth only supports issuing a Bearer token using Http Basic authentication. There are other more exotic extensions OAuth 2 with a similar flow e.g. the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (but as stated this is not yet part of DotNetOpenAuth).
im looking for good ideas/resources/implementations for the following scenario
A MVC website at http://mywebsite.com
A Webapi REST service at http://myapi.com
IMPORTANT -- Please notice the separate domains/Applications..
A user logs in at the website and data is fetched from the API via JSONP/CORS
Obviously i dont want the user to authenticate on the webapi using basic authentication. But the API is also exposed to Android/IOS apps, so i need the basic auth
I've thought about returning a token from the MVC site and then writing a DelegatingHandler at the webapi site to authenticate using that token, but i would like some inputs, or perhaps even better solutions
I made a pretty diagram just for the occation:
Although JSONP works also consider using CORS some examples of WebApi implementation here.
Consider following a standard (at least a draft) for your token rather than creating your own. Json Web Token (JWT) seem to be a good approach the specification here includes the format and determines the encryption or signing approach. There are libraries to support this kind of token such as the Thinkteckture Identity Model this article covers some of the usage of that library and the JWT. Google have a good dev guide here.
Disclaimer, only consider the above having read about some of the OAuth and JWT standardization criticisms.
If you did use a HTTP header, I am not sure you need a custom header (#Vipul) the "Authorization :" header is there for this kind of information.
If you are using a custom token, ensure it has an expiration date, consider using a nonce if you want to protect against replay attacks and sign or encrypt using a well known algorithm.
Agree with you that delegating handler is a good place to put token validation. An ActionFilter is called much later than necessary in the stack and the middle ground would be to implement System.Web.Http.AuthorizeAttribute.
token solution sounds good.
Get the authentication token from MVC application, you can send that token with each API request in some custom header. Create an ActionFilterAttribute and in OnActionExecuting you can verify the token and act accordingly.