I'm trying to secure a small dot net core mvc and api application and I've gotten turned around and need a little direction.
I've got to use ADFS 3.0 Server2012 R2 as the source of login/password.
I have to use versioning in the API. (Microsft.aspnetcore.mvc.versioning)
I don't want to send a login/password to API, just a bearer token.
I configured cookieauthentication and OAuth against the ADFS endpoint and it works fine for the mvc ui, but I don't know how/what to do to get the API to work with httpclient from the mvc ui controller to the API.
Long ago I used IdentityServer 1 or maybe 2 and used bearer tokens but I couldn't figure out how to create a token in the OnCreatingTicket in the OAuth event and not sure where to store it. I tried a claim, but it didn't work so it might be malformed or simply wrong.
I am unsure if my issue warrants using something like IdentityServer since the site is small and i don't need a user store, everything is in LDAP / ADFS.
Can I register three middleware peices, build a token from the oauth authentication, store it somewhere like a claim and pass it through the httpclient where its verified?
app.UseCookieAuthentication(option);
app.UseJwtBearerAuthentication(bearer); //api
app.UseOAuthAuthentication(adfsOption); //mvc ui
inside the adfsOption build a token...
Everything I try gets
Message "A security error occurred"
The answer to my question is yes, its very straight forward. I'll post a gist later. My primary problem which was high jacking me was the httpclient didn't like my dev cert for ssl.
I'm still unsure if putting the token in a claim is ok. The cookie and oauth invalidate it every 15 minutes and refresh it, but randomly getting a refresh token would be very difficult.
adding this very bad code allowed it to check my token and it worked as expected.
handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => { return true; };
Related
I have an API that is also hosting an OpenIdDict token endpoint. The API does not have any web pages with login forms but instead returns an access token in a response as a result of receiving a form post.
I previously had an old AngularJS frontend which talked to the API to get the token and stored those on the client. Angular was responsible for adding the token to every request to the server.
I am now planning on rebuilding the frontend using Blazor Server. I want the new Blazor Server client/frontend to use introspection against the APIs token endpoint.
My plan was to build a custom Login page that on post would, server-side, talk to the API and get an access token, refresh token, etc. But I have no idea where to put the access token afterwards so that it's used by Blazor through introspection whenever I use the Authorize attribute. I could just return the tokens and maybe write some javascript that saves it somewhere and adds it to any subsequent http requests, but that does not feel like a Blazor Server solution?
My latest discovery is that the tokens could be stored "in session" on the server and a "session identifier" cookie is created on the client? Might be completely off here...
When I played around with the Identity support in Blazor Server a cookie with the name ".AspNetCore.Identity.Application" was always created after a successful login.
Another less desirable solution, or workaround, I have been thinking about is copying the API's OpenIdDict-setup code over to the Blazor Server project and point them to the same database.
Any help here would be greatly appreciated!
My plan was to build a custom Login page that on post would, server-side, talk to the API and get an access token, refresh token, etc. But I have no idea where to put the access token afterwards so that it's used by Blazor through introspection whenever I use the Authorize attribute. I could just return the tokens and maybe write some javascript that saves it somewhere and adds it to any subsequent http requests, but that does not feel like a Blazor Server solution?
You can store the Access Token in the local storage, and retrieve its value whenever you want to use it. Yes, it is Blazor Server solution. That is how you should do it.
When I played around with the Identity support in Blazor Server a cookie with the name ".AspNetCore.Identity.Application" was always created after a successful login.
This is true. Is this a statement or you're asking a question here ?
Anyhow, I guess this cookie will be automatically removed when its life time ends. But in your case, you'll have to do it manually; you'll have to write code that checks whether the access token has expired. If you do not do so, your app will have issues when you try to access a Wep Api endpoint. There is also the authorization components and objects in Blazor that will wrongly perform if you do not manage the stored access token, as for instance, the AuthorizeView embedded in the LoginDisplay component will show the name of an authenticated user (because the claims you extract from the access token constitutes the data from which the AuthenticationSateProvider creates the AuthenticationState object), but no checking of the validity of the access token is perform. But
accessing your web api with the current access token will result in an exception as the access token is not valid.
I've described above something that should be explained by text of hundreds of pages. Hope you're not much confused.
Here's the best place for you to start your investigation Customizing the AuthenticationStateProvider in Blazor Server App with Jwt Token Authentication
Hope this helps...
I am using JSON Web Token (Bearer) as my default Authentication. I'm then using (Cookies) as my Authentication for Google.
I am using the default Google Authentication in Asp.Net Core API to get the AccessToken. I then pass that AccessToken to my Angular application in the Url, using a redirect. This is similar to how the ASP.Net MVC 5 Web API works. From there, I'm making a call back to my Asp.Net Core API to try and get the remaining claims. I'm making the call using the AccessToken.
Does anyone know how to access the external claims using the Google AccessToken? I know how to do this in the Asp.Net MVC 5 Web API, but Asp.Net Core is much different.
I can see external claims here. This happens during the OAuth process after the User Authenticates with Google. This is in my ExternalLoginCallback method.
var result = await HttpContext.AuthenticateAsync(CookieAuthenticationDefaults.AuthenticationScheme);
Here is some information that seems to be useful, but it doesn't specifically address third party Auth.
https://learn.microsoft.com/en-us/aspnet/core/migration/claimsprincipal-current?view=aspnetcore-2.2
If I call the API using the AccecssToken, in the header, and use HttpContext.AuthenticateAsync like so....
var result = await HttpContext.AuthenticateAsync(JwtBearerDefaults.AuthenticationScheme);
I get this.
{System.Exception: No SecurityTokenValidator available for token: ya29.Glt5B_thgPhe8-FcR
Thanks in advance! Any help is much appreciated.
Here is what I ended up doing. Since I'm able to get the claims from the Cookie in my ExternalLoginCallback method, I went ahead and created a new JSON Web Token (JWT), added the extracted claims to it and then passed that over to my Angular application. Now, when I make the call back to my API, I'm able to read that Token and extract the claims using this line of code in my GetUserInfo method.
HttpContext.AuthenticateAsync(JwtBearerDefaults.AuthenticationScheme);
Bottom line, since I could not read the Google AccessToken like I could in my ASP.Net MVC 5 Web API, I just went ahead and created a new JWT Token, added in the claims and used that.
By the way, I'm having to do all of this because I can not call my ExternalLogin method directly from Angular because of a known Cors policy issue.
I have a ReactJS SPA application which connects to the ASP.NET Core WebAPI. The API is also an authorization server thanks to OpenIddict. I am using PasswordFlow and RefreshTokenFlow to handle authentication, which means that the server returns an AccessToken and optionally a RefreshToken. At this moment I struggle with handling Remember me functionality properly. When a user wants to rememebered it is no big deal - the server returns an AccessToken and a RefreshToken which the client stores is LocalStorage, so it can refresh the AccessToken when it's about to expire or is expired by using RefreshToken and it is fine - there is a lot of articles and other helpful resources on the Web. The problem comes when the user does not want to be remembered. How to handle authentication is this scenario? The two solutions I see are:
the server only issues an AccessToken, which the client stores in SessionStorage. If it expires - the client forces the user to re-enter his credentials to get a new AccessToken. AccessTokens should be short-lived (according to what I've learned so far, it can be from one up to several hours, but the more hours it is valid, the less secure it is in a situation when it gets stolen. If it lasts for an hour and after that time the user still uses the application, it seems a bit odd to force him/her to login again.
the server returns an AccessToken and a RefreshToken and the client stores it in SessionStorage. During the session, if the AccessToken is about to expire, the client can get a new one by using the RefreshToken. This is risky as well as the server will never know that the user closed his browser and that his/hers RefreshToken should be revoked. Assuming that RefreshTokens have a way longer lifetime, this seems really risky.
I will be grateful for any thoughts, suggestions and insights on this topic.
Thank you!
If you are new this stuff is tricky to understand, but most implementations work like this:
The SPA uses the Open Id Connect Implicit Flow via a 3rd party library
Users are redirected from the SPA to a 3rd party Authorization Server to login
The Login Process is completely externalized from your app
After login the Authorization Server returns a token to your SPA
The SPA calls the API with an access token
PS: I have a code sample and some written guidance that you might find useful.
Further posts describe how silent token renewal works for an SPA, and as John points out above, an SPA does not use refresh tokens.
I'm getting lost in OAuth and OpenIDConnect and aspnet core middleware. Any help on this would be appreciated.
I have multiple UIs (web, native apps) that use the same set of web services, and I'd like to ensure only authenticated users can access the web services. My organization uses Google accounts, so I'd like to use Google authentication restricted to the organization domain.
The web site is properly requiring authentication, following this sample. What I need now is to have the web site (AngularJS 4) invoke my back end web services with an auth token that I can verify with Google.
The back end services are written with aspnet core. I've tried using these approaches: Google middleware and Google OpenIDConnect but these still 1) assume there is a UI that can prompt an unauthorized user to log in, and 2) appear to be cookie-based, and I won't have cookies for the web service calls.
I don't want to prompt the user to log in, since the "user" in this case is a software client. Either they're authenticated or not already. I just need to get the authentication token, validate it, and carry on.
This appears to be the same question, which hasn't been answered yet, either.
Any suggestions are appreciated. Also, suggestions or tips on having native apps do the same!
Got it working. As mentioned, I was getting lost, and the OpenIDConnect, though referenced in several areas as a solution, was a red herring for the web services. Here's what is working for me now, with as complete steps as I can provide (some cleanup required):
Add authentication to the UI following these directions
Obtain the JWT token as shown in the first segment here
On each web service call, include the JWT token in the headers:
Name: Authentication
Value: Bearer {token value}
Install the JwtBearer NuGet package
In the ConfigureServices method of Startup in the web service, after you AddMvc():
services.AddAuthorization(options =>
{ // this policy needed only if you want to restrict to accounts within your domain. otherwise, don't use options. or use whatever options work for you.
options.AddPolicy("hd",
policy => policy.RequireAssertion(context =>
context.User.HasClaim(c =>
c.Type == "hd" &&
("https://accounts.google.com".Equals(c.Issuer) ||
"accounts.google.com".Equals(c.Issuer, StringComparison.CurrentCultureIgnoreCase)) &&
c.Value == "yourdomain.com"
)));
});
In the Configure method, before you UseMvc():
JwtBearerOptions jwtOptions = new JwtBearerOptions();
jwtOptions.Audience = "{the OAuth 2.0 client ID credential from google api developer console}";
jwtOptions.Authority = "https://accounts.google.com";
jwtOptions.TokenValidationParameters = new TokenValidationParameters();
jwtOptions.TokenValidationParameters.ValidIssuers = new List<string>()
{
"https://accounts.google.com",
"accounts.google.com"
};
app.UseJwtBearerAuthentication(jwtOptions);
Perhaps there is a more appropriate way to do this...if there is, I'm interested in trying it out. For now, this is working.
I will try to help.
First you need to look at OpenID Connect (which is built on top of OAuth 2.0) remembering that OAuth 2.0 NOT an Authentication protocol.
1) assume there is a UI
No UI is required for login assuming you are using Google services. You only need to check for the existence of and validate the Access Token, Identity Token (and perhaps the refresh token). If there is no Token, assume the user is NOT Authenticated and redirect them to the Authentication Server with a Authorization Request.
If there is a valid Access Token and Refresh Token, then you can assume the user is Authenticated.
You can also inspect the Access Token for proper "Scopes" to determine if they are Authorized for your specific application.
If you are using Google for Authorization Server, you can validate the the hd parameter within Identity Token has the desired Domain.
BTW: No cookies involved.
Hope that helps.
I've been reading Vittorio Bertocci's blog to try to get up to speed on using ADFS to manage authentication and claims in either an MVC app or WebApi service. It looks like it's getting to be very approachable.
I am now trying to build out a POC using ADFS to do common claims resolution for internal sites/services in our enterprise. Our users would be on the internal network along with our endpoints. Right now we use Windows Integrated auth by default and each site does the work of looking up a user’s name, email, and other AD details and inspecting the claims principal for roles via IsInRole. The claims we get with integrated auth includes just a SamIdentifier and a bunch of group SIDs. I’d like ADFS to do that work for us but still give our users a challenge-free experience. Long term, we will likely add support for non-domain-joined devices on some sites/services, so that is another motivation to explore ADFS.
So I've set up a simple sample app in VS2013 using Organizational Accounts (On Premise) that will dump out a current user's claims, configured the metadata endpoint and audience uri, communicated that info along with the claims I'd like mapped to my ADFS admin (2012, btw), and deployed my site to a development server. So my host is still IIS, though I hope to use Owin middleware to set up authentication rather than web.config (WIF-style).
Given that IIS is my host, how do I configure authentication for my site: anonymous? And my web.config should specify "None" for the authentication mode and deny="?" for authorization, correct?
The other question I have that Vittorio didn't get into in his post about on-premise adfs was the nature of the bearer token and whether or not we need to explicitly configure the middleware to use cookies. My startup config looks like this right now:
public void ConfigureAuth(IAppBuilder app)
{
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
TokenValidationParameters = new TokenValidationParameters() { ValidAudience = ConfigurationManager.AppSettings["ida:Audience"] }
});
}
It looks like this middleware is expecting JWT tokens (given that there is a JwtSecurityTokenHandler on the class). Is there any configuration we need to do on the ADFS side to issue JWT tokens? My understanding is that I'll receive a SAML token by default.
And should we expect to use the CookieAuthentication middleware to manage the token or will the browser just keep including it for the life of the session?
Thanks, all!
UPDATE:
So based on Vittorio's help below and some further research, I now have a simple website with just one page protected with an [Authorize] attribute. My startup class's ConfigureAuth method now looks like this:
public void ConfigureAuth(IAppBuilder app)
{
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseActiveDirectoryFederationServicesBearerAuthentication(
new ActiveDirectoryFederationServicesBearerAuthenticationOptions
{
MetadataEndpoint = ConfigurationManager.AppSettings["ida:AdfsMetadataEndpoint"],
TokenValidationParameters = new TokenValidationParameters() { ValidAudience = ConfigurationManager.AppSettings["ida:Audience"] }
});
}
We've added my website as a relying party trust in ADFS and created a half dozen claims rules. Everything seems correct so far, but I'm still struggling. I hit the protected "claims" page and get a 401 response with a WWW-Authenticate:Bearer header. So far, so good.
But that's it. How does the browser know where to get authenticated and receive a token? If I was proving out the separate client scenario, my client would be configured with the location of the token authority, but in this simple website scenario, I'm clearly missing something.
UPDATE 2:
I wonder if the implementation for on-premise ADFS just isn't ready yet? Or perhaps the documentation just isn't there yet - or both...
I pulled out all the Owin packages and reverted to using the WSFederationAuthenticationModule and SessionAuthenticationModule, along with all the web.config settings in system.identityModel and system-identityModel.services that have been around a while. Basically, I made the solution look like the one you get from VS2013 when you selected Organizational Accounts --> On Premise. Everything works beautifully and I have all my configured claims coming from ADFS. I see the initial 302 redirect to ADFS, the challenge-response, and ultimately have a SAML token serialized into a secure session cookie. On the website, I echo back the claims like so:
var user = User as ClaimsPrincipal;
ViewBag.Claims = user.Claims;
return View();
This is why I suspect the middleware is incomplete: when you use that new template in VS2013, the wizard goes to the federation metadata endpoint you specify and builds out all the web.config settings by reading that xml and, in addition, sets some intelligent defaults. That's sort of what I expected to happen in the Owin middleware - it should have everything it needs to know since I pass in the same metadata endpoint. I was hoping that "magic" would replace using the FAM/SAM modules and all the accompanying config.
1) If you are configuring a web UX app, that is something meant to be consumed through browser redirects, you want to use http://www.cloudidentity.com/blog/2014/04/29/use-the-owin-security-components-in-asp-net-to-implement-web-sign-on-with-adfs/. You'll see that the cookie middleware does come into play in that case.
2) If you are configuring a web API, as in something that is consumed by a rich client or another server, or in general anything that is not a browser roundtripping, see http://www.cloudidentity.com/blog/2013/10/25/securing-a-web-api-with-adfs-on-ws2012-r2-got-even-easier/. In that case you do not need cookies, given that there is no session -every single call must carry the token.
HTH
V.
As Vittorio said you need to differentiate if you create a web page with web api or web api only. Follow his blog posts they are great!!
If you host a webapi only project in an IIS you need to set the authentication to "forms authentication".
This works also if your web api is covered behind a web application proxy. make sure that you configure your endpoint (published web application) not to preauthenticate. the value for "preauthenticate" should be "pass through".
bg Andrej