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.
Related
There is a requirement to have a common web api application to service 3 different MVC web applications. These client web applications have their own databases and own authentication implementations. How do we configure the web api application to provide access to a set of APIs to web app 1 alone and deny to all other web apps, similarly for web app 2 and so on? In other words, is there a way to 'register' each web app with the web api service and also build in a mechanism through which the web app is only allowed access to a set of endpoints? Thanks for all the help..
There are a handful of ways of solving this
Host multiple WebAPI servers in a single process to effectively meet your requirement while making your project easier to organize
Use Authentication and Authorization filters to customize how requests are accepted, denied, and routed
Using a router and/or switch at the hardware level, create a blacklist/whitelist combined with a reverse proxy (beware of MAC spoofing, etc, with this solution)
Use dependency injection to add abstraction to the process and to remove the ability to specify a custom endpoint in an unintended manner programmatically; this solution will only work if you control the client code, however
From the sound of it, the issue you're describing doesn't seem like one regarding the visibility of the endpoints, but of the access control to leverage them. If I'm wrong, please let me know in a comment and I'll update my answer.
My Google-foo is failing me here... most likely a terminology thing.
Basically, I'm making a desktop (and likely mobile) application that connects to a REST API that returns JSON. I've created a C# class library that handles the the data querying in my local project however this would expose my API key if I were to publish it.
I would like to know what are the appropriate options for simply running a small service in Azure that takes a web request, queries the API and passes the JSON response back. Something lightweight, decently scalable.
Is this something a web role or worker role is good for? Is this something I really should learn Node.js for?
I asked a similar question a few years back: Keeping a secret key secret with Amazon Web Services
One reasonable solution is to build a simple service that returns the headers and url to use when communicating with the authenticated service. Your API key remains secret because it only lives in your service, but the clients can leverage the API key by getting the encrypted request from your service and then making the request for the actual work.
I haven't personally looked into the Azure API App Service, but a brief browse of the main website suggests that it, too, may be relevant to your interests. :)
Check out Azure Mobile Apps. Azure Mobile Apps is a "backend as a service" platform. With Mobile Apps you can easily store information into a SQL Database and expose custom API methods. It is a great place to start and has SDKs for connecting iOS, Andriod, Xamarin, and HTML apps.
As for security, the Mobile service has options to protect the data from allow anonymous access to requiring each user to authenticate.
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’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny
I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.
I've got a website which contains the profile of users. I am now working on a mobile app and I would like to access the profile details from via the app. My idea is to simply create a webservice which returns the relevant fields (some of which might be password protected). How can I ensure that the web service is being request only by my application and not by anything else (desktop, other app etc..)? Initial idea was to have a secret key embedded in the program which is used to encrypt the data sent over to the web service, but I'm not sure how difficult it would be for someone to find that key since it's on the client side app.
Any suggestions on what the best approach would be for this type of situation? (I assume the technique would be the same regardless of phone model)
Thanks
Microsoft now considers ASMX web services to be "legacy technology". All new development should be done using WCF.
WCF has many more abilities in terms of security than ASMX does.