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.
Related
I'm working on a project that uses a C# Web API. We are using JWT tokens.
We have the authentication setup for the main application that is hitting our web API.
We also have a side service that needs to authenticate to use the web API, but they do not have the necessary items to authenticate because they do not have an account.
Is there a "secure" way to authenticate a side service that does not have the normal login functionality?
Looks like you want an app that is not authenticated by login but still protected?. This is really not a very good implementation. In case you want to do this. You can try the solution using rsa body request encryption algorithms with signature includes in header and check. If it matches then you can implement your logics. Hope to be useful.
I have an Azure-based .NET Core Web API application that I want to communicate with an Azure-based MVC5 application. The MVC5 application requires its clients to have a credential in our Azure AD instance. We connect to this app with our SSO Azure AD credentials.
The .NET Core app does not authenticate against Azure; there's no credential pass-through possible for its consumers. BUT... it's hosted in the same Azure instance, so it seems like I should be able to send an authenticated request from the web api to the MVC app with relative ease.
The documentation on this is quite confusing though. There's talk about x.509 certs (this really doesn't seem necessary), OAuth 2.0 grants and flows (I may not be able to get around that, I don't know)... but is there some simple, relatively "brainless" way to have the one service talk securely with the other without building some kind of complicated scaffolding and/or configuration? I'm kinda hoping there's a way to just instantiate a HttpClient or WebRequest, call some method to get the proper Authorization header (or maybe cookie?), and send my request on its merry way... but if it exists, it remains elusive to me.
Any elucidation on this would be helpful, thanks.
This sort of depends. First, to be clear, you are trying to call an action in the MVC app from the API app? This seems a little odd (more often, a MVC front-end might need to call the api). Regardless, it should still be the same.
Question: Do you want you api app to always call the MVC app as "itself"? So, your api app would have an identity that is authorized to call an action on your MVC app? If so, this is exactly what the OAuth Client Credentials flow is for:
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service
With this flow, you create an Azure AD application registration that represents your API app. Then, at runtime, your API app uses its client id and client secret to acquire a token it can use to call the MVC app (typically passed as a bearer token in the Authorization header). Part of what you can do with the app registration is give it delegated access to your MVC app, but you can also manage which "clients" you want to allow access in your MVC app.
Hopefully this makes sense.
I am trying to capture a SAML token that my ADFS login gives me. I need to capture the SAML by browsing to the ADFS login page, Let the user login and then when login is successful return the SAML back to the application. The application tehn calls a WCF service passing the SAML token in the header. I have a Url like :
https://adfs.mydomain/adfs/ls/IdpInitiatedSignOn.aspx?RedirectToIdentityProvider=http://adfs.mydomain/adfs/services/trust&loginToRP=https://bcjbsj.com/client-api/api/saml
I need to get this working wither in a windows application or console application. If this is not possible I can create a ASP .NET application also for testing. I have gone though many links but not able to find anything that helps.
I may be missing something here. Quite new to authentication. Any help or pointers would be helpful.
This is easily accomplished using a technique (occasionally) called JavascriptNotify. The basic idea is to display a WebBrowser control that you extend via javascript to allow callbacks to your app code once authentication is complete. You need to provide either centrally or packaged with your app an SP-STS that presents the home realm discovery page and the final jsnotify page. The rest of the UI is handled by the trusted STS's. You can optionally use Azure ACS to fill this role.
See Authenticating Users from Passive IPs in Rich Client Apps – via ACS or Access Control Service: Transitioning between Active and Passive Scenarios for what the call sequence looks like.
To understand how to add the required window.external methods, see Invoke C# code from JavaScript in a Document in a WebBrowser. Thinktecture has an example client in WPF implementing javascriptnotify with JST.
As #Thuan mentions, the other option would be to abandon WS-Federation passive authentication in favor of WS-Trust active authentication. The downside in this approach is that it is far less flexible, and you must implement the client-side UI yourself. Having written apps that implemented both WS-Trust and WS-Fed RP's, I highly recommend WS-Fed passive authentication even for desktop apps.
That endpoint is used for passive login (aka via browser) scenarios. For Windows application or console, WS-Trust is a more appropriate approach. In short, your application uses WS-Trust protocol to call ADFS to get a token that can be used to access a WCF service. Such a WCF service is called claim-based service or claim-aware service. This question has a bunch of good links: WCF, Claims, ADFS 3.0
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 am going to build RESTful web service using C# (maybe ASP.Net MVC) to consume on my iPhone app.
I have been surfing few days, and I found this could be good start point.
http://www.codeproject.com/Articles/233572/Build-truly-RESTful-API-and-website-using-same-ASP
But I have noticed there are only for customers and orders related APIs.
The APIs what I want to build are "user login" and "register user" features.
There is "User login" feature on the view, but it is only for ASP.NET membership provider related, not RESTful web service API.
How can I build this web service API for login, register user?
Any advice?
The concept of being able to login in the traditional sense is a stateful behavior. REST philosophy IMHO is leaning more into being stateless.
Some approaches that you may want to consider are 1) HTTP Basic Authentication, 2) OAuth, 3) OAuth2.
In the case of HTTP Basic Authentication for example, the username and password are combined in a hash and is packaged into the HTTP request as an authorization header. For every request that arrives the server can look into the request header and validate the username and password. Because the credentials are submitted for each and every request the server have no need to maintain state.
If you really need to maintain a login state it is probably better to implement it on the client side.