This question is not about HOW something can be done. Everything is working fine. I like to know, if it is "ok" to do the authentication / authorization process inside a WCF message inspector.
Currently I am working on a client/server application with a WPF client and a self-hosted WCF server. The used protocol is Net.Tcp and all SOAP messages are AES256 message-encrypted and signed. Also all send SOAP message-headers are always message-encrypted and signed.
The complete auth process looks like this:
Both server and client are always sending certificates to authenticate each other
Client receives a list of all endpoints it can connect to
Client sends User/Pass to authenticate and gets a session-id from the login-service
The session-id, the user-id and all user-rights associated with the user-id are stored into RAM in a singleton service, which is available system-wide inside the server application.
On every further request after the first login, the client only sends the session-id and a certificate inside a custom message-header, no more user/pass combination.
The situation:
Before a request from the client reaches any webservice operation, a message inspector reads the session-id and the requested webservice operation. It then uses the available singleton-service to determine if the session-id is still valid and if the associated user-id has the right to do this webservice operation. If not a fault-exception is thrown.
The question:
Is there anything wrong, to do the authentication / authorization process inside a WCF inspector?
If its working then dont break it :) But to answer you, I have put some insights for your to consider:
1- For service operations that dont require authentication, you would have to change the inspector code to whitelist them. This contradicts with the open close principle where your class must be open for extensions and closed for modification.
2- If later on, you decide to modify your authentication mechanism and use a third party component, you would have to modify your interceptor code drastically.
I usually use the WCF inspector to pass the token and other related info into my services classes where i normally implement the cross cutting concerns (Validation, Authentication, Authorization, Logging and exception handling). When you inject your authorization engine into your services, it becomes easier for you to first swap the mechanism when need be, second unit test your service method in isolation of whatever authentication mechanism you are using.
Related
I have a client, which calls a service (passing it a user id and password). The first service can validate these credentials against users in a database. The first service then needs to call another service, but this second service cannot be passed the user id and password given to the first service (this is a requirement outside of my control).
The services will most likely be on different domains and both exposed to the internet (so security is a big issue here).
I am therefore looking at options for how the second service should check/validate that it is being called by my first service (and not by someone else trying to impersonate it).
One idea I've had is to add an additional service that acts as an authentication service, this could issue a token that is then passed to the second service which in turn calls the authentication service to check the token. Another idea (from a colleague) has been to assign an SSL certificate to each service, and check the certificate when the call comes into Server B - I haven't seen certificates used in this way though so am not sure if it's viable.
This is still at the design stage, so I am open to alternative ideas/approaches.
If you need an easy fix, then creating an extra set of credentials for service A so that service B can be sure it's called from an authorized party without knowing the clients credentials might be enough.
In the long run, something like Windows Identity Foundation sounds exactly like your plans with the authentication service.
So, both A and B parties are exposed to the internet (distrusted environment). Taking into account security requirements what you need is mutual WCF authentication. Certificates are the easiest way to achieve the goal - your server has to ensure that proper client calls it and the client has to be sure it calls proper server (DNS attacks, etc.). That means each party must have public key of the other to authenticate. Check this article for the details on how to configure your server and client.
I have REST API and to make it more secure I would like restrict the access to the registered applications or websites only.
Now these client applications could be web app or mobile app under Android/Windows/BlackBerry/Apple etc.
Also I can't ask the client apps to modify there code to store any value being provided by my rest API to get registered. (as these apps may or may not be using database or other persistent media).
WCF REST API should not that the caller is registered with it or not.
Any suggestions how to do it.
Using HTTP Basic Authentication (as long as your REST service is running under HTTPS) is a pretty standard way to do this. You then generate a login/password for each registered app that you want to access your API.
[EDIT: more details here: http://en.wikipedia.org/wiki/Basic_access_authentication
Basically when a client connects they need to Base64 encode their username/password and attach it into the standard HTTP Authorization header. Your server application reads the header, decodes and extracts the username/password and checks it with your list of authorized applications.
NOTE - the header is only base64 encoded, so the username/password are effectively plain text. You really should be running HTTPS if you want to use this authentication method, otherwise the header is open to interception]
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'm currently developing a web api, with WCF web api, which allows me to write restful apis. One concern I have is security. For this reason I decided to protect my api with the OAuth protocol which works very good. However, the team got to the conclusion that our own applications shouldn't be authorized by oauth, instead they sould be authorized by http basic, meaning that the client application should send username and password.
So I have 2 questions:
How can I set up WCF Web Api to work with SSL, I'm using Web Api preview 6, and the project is a MVC3 application?
I have an operation handler which takes care of the creation of IPrincipal from the client access token, and then injects it into the operation parameters, so I can access the user's info. I would like to have in the same operation handler a condition where I could check if the authorization scheme is OAuth or http basic, and then in the case of http basic extract the user's credentials and authenticate that specific user against my data base, if authentication is successful create an IPrincipal and inject it to the operation parameters. However, as I see it, everytime an application using http basic requests something to the api, I would have to go to the data base and authenticate. So my question is: Am I in the right path, or this could be accomplished in some other way?
Any answers would be appreciate it. Thank you in advanced!
You setup SSL for WCF Web API just like you would any other WCF service exposed over HTTPS. If you are hosted in IIS, then you need to configure a site binding for HTTPS. If you are self hosted, then the configuration is bit more involved. See http://msdn.microsoft.com/en-us/library/ms733768.aspx for all of the details.
To handle basic auth against a custom identity provider you would typically use a custom authz module when hosted in IIS. See [http://custombasicauth.codeplex.com/] for an example of how to do this. If you are self hosted then you can use a custom username passworld validator. See http://msdn.microsoft.com/en-us/library/aa702565.aspx for details.
Yes, I believe you are correct that every request will require authentication unless you establish some sort of session-like semantics.
Hope this helps.
Using Windows Identity Foundation I have a user who is successfully logged in and able to request pages. But there is an issue on any page that relies upon a asmx web service request to a WIF protected resource.
Is there a way to add SAML information to an asmx request similar to how you would add it to a WCF request?
I think what you want is a custom header in your soap messages.
you can then use that to specify the user credentials from which the action is being performed.
It's a fairly advanced subject this ...
2D00-a-solution.aspx">http://weblogs.asp.net/avnerk/archive/2006/04/26/Adding-custom-headers-to-every-WCF-call-2D00-a-solution.aspx
but the idea is that you are kind of adding a constraint to the calls that the service accepts shaping the packet to ensure that the credentials are wrapped up.
the other way of course is to go back to basics and basically build a lump of xml (soap packet) and then use the request and response classes to manually process the information (not ideal)