Here's my situation. I have two different Web Applications (App1, App2), both with an implementation of WIF and AD FS. They both have Web API controllers, and all calls are secured with WIF. This means that whenever I do an unauthenticated call to my Web API functions, it's redirected to the ADFS login page. They both use the same instance of AD FS, so single-sign-on works.
However, this redirect behavior is problematic in a particular scenario. Let's say that I login through App 1. From App 1, I want to call a WebAPI function on App 2, using an HttpClient or a similar class. My call fails, because it's always redirected to the ADFS
I'm guessing it's because I need to pass my security token somehow, but I haven't figured out how. Any help about how I could do this would be greatly appreciated.
TL;DR: Can I call a Web API function secured by WIF/ADFS through a client in .NET code?
Thanks!
IMHO opinion web api is not compatible with a passive WIF redirect. This does not mean you can't protect your web api; it just means that a passive scenario is not ok for this. Web api, by its very nature calls more for an active scenario where you get your security token from your STS through code, not through the redirects of a browser (in web api there normally isn't any browser). Then your need to pass your security token along with the web api call (normally through some http header like x-authorization) There is not standard for this but some good ways are documented in a book like web api security. This means your have to write some actionfilters yourself to get the security token out of the header. I addition, I think the ThinkTecture libraries offer some off the shelf support for securing web api's.
Related
Vue front-end for SPA and asp.net core 3.1 as backend for API
Using Microsoft.AspNetCore.SpaServices.Extensions nuget package so, among others, SPA files will be served from a folder (wwwroot/dist) when users access .net core
Back end API controller is decorated with [Authorize] attribute
SPA router has authguards so protected routes are only available to authenticated users
SPA will use Axios and pass a bearer token to the back end API
I want to implement OAuth2/Oidc authorization code with pkce using the identityserver4 hosted on another system.
A request for the landing page should forward the user to identityserver4 for the login/password prompt and redirect back after completing all the steps with a token.
Ideally I want the .net core handle all the oauth/oidc steps and don't want to deal with it using oidc-client javascript client in SPA. Any suggestion on how I can accomplish this? Thanks
Well there are two standard models here and you need to choose one of them, depending on factors you care most about:
OPTION 1: SPA SCENARIO
The SPA is the OAuth client and authenticates via Javascript tech
The API is the OAuth resource server
It is not standard for a resource server to handle the authentication flow for a client - instead a client should authenticate, then call the resource server.
OPTION 2: WEB BACK END SCENARIO
People most commonly choose this option when they want to keep tokens out of the browser's Javascript code:
A Web Back End in C# is the OAuth client
The Web Back End needs to securely communicate with the browser and has to use an auth cookie for this
To call an API the browser needs to either send the cookie to the web back end to get a token, or double hop all API calls via the web back end
ABOUT OIDC CLIENT
Personally I prefer option 1, which I think is closer to overall SPA Goals, such as cross domain hosting and use of content delivery networks. OIDC Client can actually lead to a fairly simple SPA security implementation, as in this
Client Side Implementation of mine.
I am creating a mobile application which will talk to my REST Web Services, for login, GET, POST, DELETE and logout. I have been trying to figure out how to secure these REST Web Services using Keycloak. I do not want any In Browser Login on the mobile application, so I was inclined towards Direct Grant API and Admin REST API for authentication and token validations. But, now after looking at the available options on Keycloak, every request from the mobile app must be intercepted, and then make a REST call to the Keycloak module for validating the token and then return a response back to the mobile app.
Is there a better way in doing this? Some inbuilt function calls to check the token validity instead of making an HTTP call for every request from the mobile app? I think this is a huge overhead.
My server is on JBOSS. Spring, Resteasy and Keycloak-services are being used to figure out a solution for this problem.
I'm writing a fairly large application, with a HTML/CSS/JS frontend, using AngularJS and a ASP.NET MVC Web API as a backend.
I would like users to be able to authenticate, I've installed ThinkTecture AuthorizationServer on a separate machine, and there is an ADFS instance running on the Domain Controller. Currently, I'm using the web page supplied with ADFS for login, but it would be nice if I could use my own page, which would ask for the username/password combo, pass it to AuthorizationServer/ADFS, and then just use the authentication token after that.
Has anyone done something similar?
Regards,
Daníel
In fact you user will be log in your SPA then you have a server side (Java or .NET or *) that get this request.
The server ask the token to ADFS , ADFS send the token and your server pass the token to AngularJS in the response via a cookie.
In Angular side nothing to do expect an http interceptor to check the status of the response (401,403) ...
The cookie will be resent automatically by AngularJS in each request if you want to know how implements an htppInterceptor on AngularJS just check :
AngularJs -.net MVC WebApi Authentication example
In this thread i explain how to implements this step.
Anyway : your SPA is a RIA ok but still the client part of a webapp. I don't think that it's really good (i think it's really bad) to let the client part contact directly the ADFS ... How to prevent Man-In-The-Middle if you do that ?
I have a web service built with WebAPI that accepts JSON requests and responds accordingly. The core architecture is built but there isn't any authentication/authorization.
After a lot of googling and poking around sample projects, I'm not sure where to start. I've found a ton of material from 2008 and 2009 but not a whole lot of recent guides/workflows for WebAPI / single page apps. I think the workflow should be as follows:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
Let the user log in / register: How is this data encrypted/decrypted? Surely I can't be sending passwords over the wire... is this where SSL comes in?
Provide them with access to what they have rights to access: I think I got this - I can just authorize in the controllers on a per-request basis.
Any info would be awesome.
Basically you need a token based authentication or authorization.
If you are referring to the ASP.NET WebAPI, the following project will be a great place to start:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
Even if you are not using ASP.NET WebAPI, the following video is a great introduction on how to provide authentication/authorization on RESTful web services:
http://vimeo.com/43603474
To answer some of your questions:
Check to see if the user is logged in: How can this be done with javascript? Do I send a cookie to my webAPI? If so, do I send that cookie as a parameter in the body of the request?
You can use a cookie but I normally use the header in order to avoid common XSRF attacks. Cookies are automatically included whenever a http request is sent from the browser.
is this where SSL comes in?
Yes. If you are going to go ahead with the token based approach, you can use a separate server (Identity Server) to do the authentication for you.
JavaScript clients are unique. Do you have the Web API and the page serving up JavaScript in the same domain? If not, you have same origin policy restrictions. If you have the same Web application hosting the web pages and Web API, you can use forms Authn. In that case, you don't need to send the cookie containing the authentication ticket yourself from JavaScript. Browsers do that for you and that is the cause of XSRF problem. You have to be careful about JavaScript sending credentials that the end user is not supposed to know. If JavaScript knows something, any intelligent end user can get to that knowledge. OAuth 2.0 implicit grant could be a good choice. The end user enters the credentials (password) in the authorization server which issues an access token. JavaScript gets the token and presents it to the web API but it will never have access to the credentials.
From most of the reading I've done on OpenID, it seems a browser may be required. I'm writing a WCF app and wanted to use OpenID as the authentication method, but my app is not a web app. Is it possible to use WCF and OpenID together without requiring a web browser?
While OpenID can tout in its spec independence from cookies and such because the spec doesn't actually mandate how those things are used, in reality I've never seen a good OpenID solution for anything besides logging into a web site, which is really its primary use case.
However there is a good way to go and still use WCF and OpenID. Add OAuth to the mix. The DotNetOpenAuth library has a sample that shows how a WCF client can get authorized to call a WCF service via OAuth, where at the service-side the user uses OpenID to log in as part of the authorization process.
So basically if you WCF app needs to "log in" in order to call the WCF service, as part of a one-time setup:
The app pops up a browser where the user sees the WCF service web site (the OAuth Service Provider)
The user logs in with their OpenID (although the user may already be logged in, in which case they can skip this step)
The OAuth SP asks the user "do you want to authorize this [wcf app] to access this site?"
The user says yes, and closes the browser.
The WCF app now has access, thanks to the OAuth protocol, to the WCF service.
This works because behind the scenes, when the user says "yes" to the service through the web browser, a special machine-friendly credential is assigned to the WCF app, which it uses with every WCF service call the a similar way a username/password would be.
Check out the DotNetOpenAuth library. It has the sample and everything you should need to get this working.
From reading the OpenID Authentication 2.0 Specification, I seem to have arrived at an answer:
While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with "AJAX"-style setups. This means an end user can prove their Identity to a Relying Party without having to leave their current Web page.
OpenID Authentication uses only standard HTTP(S) requests and responses, so it does not require any special capabilities of the User-Agent or other client software. OpenID is not tied to the use of cookies or any other specific mechanism of Relying Party or OpenID Provider session management. Extensions to User-Agents can simplify the end user interaction, though are not required to utilize the protocol.
Now I just need to figure out a clever way to get it to work with a WCF-based relying party...
Take a OpenIdMembershipProvider (maybe others exist).
Then configure Message security in WCF, with Username authentication, then you can use the ASPNET MembershipProvider to authenticate your user.
I don't think you can find an easier solution ;)