I have a big system. This system consist of client desktop app and many wcf services. Each of wcf service have it's own logic and isolate it from client code. One of the services is authorization service. It's main task is to authenticate user and let all other services to know what user is logged on without additional stuff. For example, as i think i should at the start of client to make authentification of the user, check it's login and password and next generate some token and use this token in all requests to other services to let any service know what user is working with it. Well, firstly, i wanted to use claims authentification, but it is quite complicated for realization. Now an idea of my algorithm is to generete some kind of token, put it into the header of any request and pass to services. Service will send this token to the authorization service and service will check it.
The question is: is there any more beautiful and more easy for realization algorithm to let any service know which user is now working with him? Or maybe wcf have some standard solution for this problem?
Update 1. I can't use active directory and any windows default authorization mechanism. I have my own database of users, their roles and permissions. I need just to let other services to know the name of the user. I need to write this mechanism once and let other developers to use it in any wcf service of our system. Is it a bad idea to send a login in every request?
Related
I decided to try for the first time to implement a microservice architecture instead of a monolithic one and ran into an authorization problem.
In a monolithic architecture, I simply passed the token in the header when accessing the controller on which the [Authorize] attribute was hanging and checked it against the current single database. But in the microservice architecture, each microservice has its own database, how you can check the token when accessing other microservices, I have heard about the implementation of the check in API Gateway, but I think that, anyway, each microservice should have its own check, since, there should be no access to the api if the user is not authorized.
Should I use api gateway to make a request to the authorization microservice for verification?
How can I implement this?
I have a separate microservice for user authorization (registration, login, issue of tokens) which has a database of users with tokens.
That is, I need to make a request to this microservice using API Gateway?
One way -
You should try to do authentication/authorization at API Gateway level. Whenever any API call come to API Gateway that needs some permission then check the token. If the access/token is not present then return 401. On frontend, if you get 401 then do authentication at UI.
2nd Way -
UI pass token to API Gateway that will further send the token to other microservices.
It depends on, how grain level of permission do you need. If it is at very grain level, then go with 2nd else go with 1st.
I have a server-client project written in c#.
I want to change the client side to a web client so we can open it with the browser. So I decided to make a WCF rest service that will replace the server side. The binding that I am using for the service is webHttpBinding.
My problem is with the behavior of the service. The service data (vars etc..) is initialize after every call. If i add the [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
it doesn't change anything. If I use [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)], it works but I guess that the service instance will be the same for every client.
I have a simple html web page that get a username and password from the client and post it to the service. The service check the Login info with the user database and response. My problem is that i can't save the user status as logged in or not because after every post/get method the service is reset.
what should I do?
This is a pretty standard issue you have to deal with when trying to maintain a session over HTTP, which is what webHttpBinding is using. Even if you try to force it to have a session, it won't. RESTful services don't work that way.
A high level overview of what you have to do is have the service create a token it gives the client upon initial authentication (probably to be stored in a cookie), which the client will then send back with each request. The service can then use that token to check if the client is logged into a particular account with each request. You probably want to make tokens expire after a certain duration (might be 1 month, 1 week, 1 day, 10 minutes, depending on your application).
You can find some more information here:
RESTful Authentication
SPA best practices for authentication and session management
Authentication, Authorization and Session Management in Traditional Web Apps and APIs
i need to build this architecture and i need some orientation on "how should i build". I've read many docs and examples but i can't find and figure how to do trying to be efficient and secure:
External app (android app, ios app) where users, after a login, can access to their personal info and manage the account (updating personal data, showing personal documents related to their account and much more). The username / pwd input must be done only 1 time.
A public wcf service will receive their actions and will call to a another internal wcf service. It will work like a 'bridge'.
The internal wcf service will get the request and do the operations needed (logical and db operations). This will return data to the external wcf service and this one to the client (obvious).
UserName/PWD are stored in a database.
WCF services can only be accessed with the correct credentials and are IIS hosted.
So i find many problems/questions:
I don't know HOW and WHERE should I build the AUTH (internal, external, both?). How can i manage a session between wcf services and app clients to avoid sending credentials every time?
The client app needs to send credentials every time? This means every service requires to SELECT the database for checking the username?
SOAP? Rest Services? It doesn't care? (on internal wcf, external wcf, both?).
I need work with asp.NET sessions or i really don't need? I don't see how services that needs username/pwd that are called frequently and repeatedly are efficient without old asp.net sessions.
Thanks for your help and orientation.
Regards!
If someone interested... seems Routing Service seems to fit for my design and can solve my problem after some tests i have done.
I am trying to implement role-based authentification to the REST WCF service . I read a lot of information on this theme but didn't got a clear understanding of what I have to do.
I understand how to restrict an access to the service using the [PrincipalPermission] attribute but don't know how to check whether the user belong to the certain role or not.
Therefore I will be very grateful if somebody can direct me to the right way (e.g. make a roadmap what should I do to achive this goal).
Let me describe this situation. I have a remote services which hosted on the server A and ASP.Net MVC client hosted on the server B.
All of these rest services has an access to the database where I can read an information whether the user has access to the service or not.
OK, Tequila, IMO what you really want, based on your description, is a normal, REST WCF service with a Login(ID as string, PWD as string) method that (perhaps) returns a SessionID. This Login() or SessionID() check method would then preceed access to all of your other methods. And since it's a webHTTPBinding -- effectively a stateless web service -- you'll need to check the SessionID or ID/Password before each request is processed.
So the workflow would be something like this:
1) client sends Login() request to host
2) host checks ID/Password against DB, creates SessionID in DB that times out after x hours, forcing new Login(). SessionID is returned in response to client,.
3) In all subsequent requests, client must provide that SessionID. That SessionID would be checked on the DB, returning stored information about the client (Role, name, ID, address ... whatever is useful) before the remainder of the request is processed.
There are methods for authenticating users BEFORE the request gets to your working code (like client authentication using Forms or client certificates (see http://msdn.microsoft.com/en-us/library/ff405740.aspx)). This shifts the Login() / SessionID check to a method executed BEFORE the request hits your main program, but the steps are basically the same.
And since passing ID/Pwd in clear text over the web is a no-no, you'd want to implement SSL on your web service (see http://msdn.microsoft.com/en-us/library/ff650785.aspx)
Everything I've describe is basically platform independent, so if you'll have iOS or Android clients, there's nothing in what I've described that would prohibit those OSs from successfully interacting with your web service.
Good luck.
I am building a client program that interacts with a WCF Service via Internet. Everything works as intended but I am wondering how I can protect my services so that only my client program can make use of it?
Right now everyone with the correct URL to my services can use it with WCFTestClient (e.g).
What is the best way to make it private so only my clients can make use of the service? Rotating token strings? Certificate? Password?
I have no idea and haven't found anything useful on the Internet.
Best regards
UPDATE: The client program is intended to be downloaded for the public (everyone). So it is not for internal use, it will be a service we are gonna provide, ones in official production.
My own thinking was like: Bind a certificate in my client programs (if thats possible even?). On the IIS where the WCF service is running, check for valid certificate. Is that possible? Or better solutions out there?
Protect .net Web Service URL
Along with the other answers, that can't be bad too,
and if you want to be super careful you can implement a token system, where the clients get the first token from you, each request returns a new token, and you always check a client vs it's current token (but that's being over careful in my opinion)
Update - because it's for the public, the client can have a way of generating a valid token to check on the server, you can have a token be valid for an interval of seconds, so even if people caught the request and found the token, it will not be valid after ..15 seconds or 30,etc
If you are using Form Authentication then you can leverage the ASP.NET to check for FormAuthentication Cookie by enabling AspNetCompatibilityRequirementsMode to Required
Or if your service is stand alone i.e is consumed by everyone then you can use oauth authentication you can read more about it Oauth Authentication
What you could do is there would be a consumer secret key which would be shared to all authenticated clients. The caller would sign some info using this key and server would also sign it using the same key and then compare it.
Hope it helps