Develop Reference

User.Identity fluctuates between ClaimsIdentity and WindowsIdentity

I have an MVC site that allows logging in using both Forms login and Windows Authentication. I use a custom MembershipProvider that authenticated the users against Active Directory, the System.Web.Helpers AntiForgery class for CSRF protection, and Owin cookie authentication middle-ware.
During login, once a user has passed authentication against Active Directory, I do the following:
IAuthenticationManager authenticationManager = HttpContext.Current.GetOwinContext().Authentication;
authenticationManager.SignOut(StringConstants.ApplicationCookie);
var identity = new ClaimsIdentity(StringConstants.ApplicationCookie,
ClaimsIdentity.DefaultNameClaimType,
ClaimsIdentity.DefaultRoleClaimType);
if(HttpContext.Current.User.Identity is WindowsIdentity)
{
identity.AddClaims(((WindowsIdentity)HttpContext.Current.User.Identity).Claims);
}
else
{
identity.AddClaim(new Claim(ClaimTypes.Name, userData.Name));
}
identity.AddClaim(new Claim("http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider", "Active Directory"));
identity.AddClaim(new Claim(ClaimTypes.NameIdentifier, userData.userGuid));
authenticationManager.SignIn(new AuthenticationProperties() { IsPersistent = false }, identity);
My SignOut function looks like this:
IAuthenticationManager authenticationManager = HttpContext.Current.GetOwinContext().Authentication;
authenticationManager.SignOut(StringConstants.ApplicationCookie);
Logging in is performed via a jQuery.ajax request. On success, the Window.location is updated to the site's main page.
Logging in with both Forms and IntegratedWindowsAuthentication (IWA) works, but I've run into a problem when logging in with IWA. This is what happens:
The user selects IWA on the login page and hits the submit button. This is sent to the regular login action via an ajax request.
The site receives the request, sees the "use IWA" option and redirects to the relevant action. 302 response is sent.
The browser automatically handles the 302 response and calls the redirect target.
A filter sees that the request is headed to the IWA login action and that User.Identity.IsAuthenticated == false. 401 response is sent.
The browser automatically handles the 401 response. If the user has not authenticated using IWA in the browser yet, they get a popup to do so (default browser behavior). Once credentials have been received, the browser performs the same request with user credentials.
The site receives the authenticated request and impersonates the user to perform a check against Active Directory. If the user passes authentication, we finalize SignIn using the code above.
User is forwarded to the site's main page.
The site receives the request to load the main page. This is where things sometimes go awry.
The User.Identity at this point is of type WindowsIdentity with AuthenticationType set to Negotiate, and NOT as I would expect, the ClaimsIdentity created in the SignIn method above.
The site prepares the main page for the user by calling #AntiForgery.GetHtml() in the view. This is done to create a new AntiForgery token with the logged in user's details. The token is created with the WindowsIdentity
As the main page loads, ajax requests made to the server arrive with ClaimsIdentity! The first POST request to arrive therefore inevitably causes an AntiForgeryException where the anti-forgery token it sent is "for a different user".
Refreshing the page causes the main page to load with ClaimsIdentity and allows POST requests to function.
Second, related, problem: At any point after the refresh, once things are supposedly working properly, a POST request may arrive with WindowsIdentity and not with ClaimsIdentity, once again throwing an AntiForgeryException.
It is not any specific post request,
it is not after any specific amount of time (may be the first/second request, may be the hundredth),
it is not necessarily the first time that specific post request got called during that session.
I feel like I'm either missing something regarding the User.Identity or that I did something wrong in the log-in process... Any ideas?
Note: Setting AntiForgeryConfig.SuppressIdentityHeuristicChecks = true; allows the AntiForgery.Validate action to succeed whether WindowsIdentity or ClaimsIdentity are received, but as is stated on MSDN:
Use caution when setting this value. Using it improperly can open
security vulnerabilities in the application.
With no more explanation than that, I don't know what security vulnerabilities are actually being opened here, and am therefore loathe to use this as a solution.

Turns out the problem was the ClaimsPrincipal support multiple identities. If you are in a situation where you have multiple identities, it chooses one on its own. I don't know what determines the order of the identities in the IEnumerable but whatever it is, it apparently does necessarily result in a constant order over the life-cycle of a user's session.
As mentioned in the asp.net/Security git's Issues section, NTLM and cookie authentication #1467:
Identities contains both, the windows identity and the cookie identity.
and
It looks like with ClaimsPrincipals you can set a static Func<IEnumerable<ClaimsIdentity>, ClaimsIdentity> called PrimaryIdentitySelector which you can use in order to select the primary identity to work with.
To do this, create a static method with the signature:
static ClaimsIdentity MyPrimaryIdentitySelectorFunc(IEnumerable<ClaimsIdentity> identities)
This method will be used to go over the list of ClaimsIdentitys and select the one that you prefer.
Then, in your Global.asax.cs set this method as the PrimaryIdentitySelector, like so:
System.Security.Claims.ClaimsPrincipal.PrimaryIdentitySelector = MyPrimaryIdentitySelectorFunc;
My PrimaryIdentitySelector method ended up looking like this:
public static ClaimsIdentity PrimaryIdentitySelector(IEnumerable<ClaimsIdentity> identities)
{
//check for null (the default PIS also does this)
if (identities == null) throw new ArgumentNullException(nameof(identities));
//if there is only one, there is no need to check further
if (identities.Count() == 1) return identities.First();
//Prefer my cookie identity. I can recognize it by the IdentityProvider
//claim. This doesn't need to be a unique value, simply one that I know
//belongs to the cookie identity I created. AntiForgery will use this
//identity in the anti-CSRF check.
var primaryIdentity = identities.FirstOrDefault(identity => {
return identity.Claims.FirstOrDefault(c => {
return c.Type.Equals(StringConstants.ClaimTypes_IdentityProvider, StringComparison.Ordinal) &&
c.Value == StringConstants.Claim_IdentityProvider;
}) != null;
});
//if none found, default to the first identity
if (primaryIdentity == null) return identities.First();
return primaryIdentity;
}
[Edit]
Now, this turned out to not be enough, as the PrimaryIdentitySelector doesn't seem to run when there is only one Identity in the Identities list. This caused problems in the login page where sometimes the browser would pass a WindowsIdentity when loading the page but not pass it on the login request {exasperated sigh}. To solve this I ended up creating a ClaimsIdentity for the login page, then manually overwriting the the thread's Principal, as described in this SO question.
This creates a problem with Windows Authentication as OnAuthenticate will not send a 401 to request Windows Identity. To solve this you must sign out the Login identity. If the login fails, make sure to recreate the Login user. (You may also need to recreate a CSRF token)

I'm not sure if this will help, but this is how I've fixed this problem for me.
When I added Windows Authentication, it fluctuated between Windows and Claims identities. What I noticed is that GET requests get ClaimsIdentity but POST requests gets WindowsIdentity. It was very frustrating, and I've decided to debug and put a breakpoint to DefaultHttpContext.set_User. IISMiddleware was setting the User property, then I've noticed that it has an AutomaticAuthentication, default is true, that sets the User property. I changed that to false, so HttpContext.User became ClaimsPrincipal all the time, hurray.
Now my problem become how I can use Windows Authentication. Luckily, even if I set AutomaticAuthentication to false, IISMiddleware updates HttpContext.Features with the WindowsPrincipal, so var windowsUser = HttpContext.Features.Get<WindowsPrincipal>(); returns the Windows User on my SSO page.
Everything is working fine, and without a hitch, there are no fluctuations, no nothing. Forms base and Windows Authentication works together.
services.Configure<IISOptions>(opts =>
{
opts.AutomaticAuthentication = false;
});

IdentityServer4 - user permissions on the API

I'm currently setting up a new project with a Web API and a MVC UI (will eventually have a mobile UI as well which can talk to the same API).
So, I have the following plan:
User navigates to the MVC UI which takes them off to the IdentityServer4 server to log in or sign up
IdentityServer user is then added to the applications own user table in the database
Permissions can then be set on the user to limit their access
This means the identity server is just that, an identity server (and means I allow people to log in through Google, etc. without worrying about their roles and permissions).
So, to achieve the above, I need to check the user's permission on the API, NOT on the client (the client could be anything - web, phone app, JavaScript client, etc. so we can't rely on that to handle user permissions).
On the API, I have implemented a Permissionhandler and PermissionRequirement authorization policy. So, on the API controller or method, I can do something like: [Authorize(Policy = "CreateUser")]. It looks like I'll need to have a policy per system permission.
So in the authorisation handler I need to:
Get the current user's username
If they exist in the app database, check their permissions and auth or deny
If they don't exist in the app database, add them, then we can set their permissions later from the admin panel
This was going well up until I tried to request the user's username from the identity server. I understand I need to use the UserInfoClient to do that, but I can't figure out how to use the user's token/credentials to get their claims from the identity server or to at least get their User.Identity.Name.
Now I could just use the sub ID to add the user to the application database, but then whoever's managing the permissions would have no idea who that person is, so I need to use their email really.
Now in the MVC client, I can see User.Identity.Name without any problems, but in the API that value is null!?
So my question is: how on earth do I get the current user's Identity.Name, username or email from within the API?
Thanks.

Think I've cracked it now.
var mvcContext = context.Resource as Microsoft.AspNetCore.Mvc.Filters.AuthorizationFilterContext;
if (mvcContext != null)
{
// Use the UserInfo endpoint to get the user's claims
var discoveryClient = new DiscoveryClient("http://localhost:5000");
var doc = await discoveryClient.GetAsync();
var accessToken = await mvcContext.HttpContext.Authentication.GetTokenAsync("access_token");
var userInfoClient = new UserInfoClient(doc.UserInfoEndpoint);
var response = await userInfoClient.GetAsync(accessToken);
var claims = response.Claims;
}
This is detailed right at the bottom of https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies so according to Microsoft, it's the right way.
You did however spark this idea, thank you Win. I had been staring at this bloody thing for hours. All you need sometimes is someone else to say something, anything, and the curse is broken! :)
I am still open to a better way of achieving this, if anyone has one.
Cheers

I believe you already configure IdentityServerAuthentication in Web API similar like this -
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
...
app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
{
Authority = "http://UrlOfIentityServer",
RequireHttpsMetadata = false,
ApiName = "exampleapi"
});
...
}
When you make a web service call, you will need to pass the same token received from IdentityServer like this -
using (var httpClient = new HttpClient())
{
string accessToken = await HttpContext.Authentication.GetTokenAsync("access_token");
httpClient.BaseAddress = new Uri("http://UrlOfWebAPI");
httpClient.DefaultRequestHeaders.Clear();
httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
return await httpClient.GetStringAsync("api/clock/time");
}

Azure AD Authentication remembers selected account. How to stop this

To authenticate with AzureAD I put the folling Code in an Console Application
private static async Task<string> GetAuthTokenAsync(string tendent,string AppIdUri , string ClientID)
{
/*
<add key="ida:Audience" value="https://mehler.ws/ToDoWebApi" />
<add key="ida:ClientID" value="f0e91727-3edd-4b00-9630-591166a74e4b" />
*/
var authContext = new AuthenticationContext(string.Format("https://login.windows.net/{0}", tendent));
AuthenticationResult result = authContext.AcquireToken(AppIdUri, ClientID , new Uri(Settings.Default.WebApiReplyAdress));
return result.CreateAuthorizationHeader();
}
the Method AcquireToken Shows a Screen where I am asked to Input my Credentials.
I accidently selected the Account I log in with in Windows 10. Now the Screen doesn't show up any more an the application uses my Windows 10 Account automatically. Does anyone know how to fix this Problem, so that the Screen shows up again?

Token's are cached to alleviate complexity in your app. You will need to clear the token cache if you want the user to log back in... typically you would setup a logout function.
More information on token cache: http://www.cloudidentity.com/blog/2013/10/01/getting-acquainted-with-adals-token-cache/
How to logout:
authContext.TokenCache.Clear();
string requestUrl = "https://login.microsoftonline.com/{0}/oauth2/logout?post_logout_redirect_uri={1}";
Task.Run(async () =>
{
var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Get, requestUrl);
var response = await client.SendAsync(request);
});
{0} - Fully qualified name of your Azure Active Directory e.g.
yourad.onmicrosoft.com or tenant id.
{1} - The URL of your application where a user must be redirected
back after the logout is complete. This should be properly URL
encoded.

An easy way is to pass to AcquireToken PromptBehavior.Always, there's an overload for that. That will cause ADAL to ignore the cache and will ask the service for a clean prompt

I found a very simple Solution myself to once clear the Cache.
Delete Cookies in Internet Explorer / Edge ;-)
Thanks anyway for the Answers hot to implement proper Logout Code and Force Prompt for Login allways.

ADFS freshness and session sliding

I have implemented session sliding using in my customehttphandler module.
I am trying to acheive session sliding as well as getting authenticated on multiple website which share same ADFS server.
public void SessionAuthenticationModuleSessionSecurityTokenReceived(object sender, SessionSecurityTokenReceivedEventArgs e)
{
SessionSecurityToken token = e.SessionToken;
DateTime nowUtc = DateTime.UtcNow;
DateTime validFrom = token.ValidFrom;
DateTime validTo = token.ValidTo;
double totalMinutes = (validTo - validFrom).TotalMinutes;
double halfSpan = totalMinutes / 2;
SessionAuthenticationModule sam = sender as SessionAuthenticationModule;
if (validTo < nowUtc)
{
if (sam != null)
{
sam.DeleteSessionTokenCookie();
e.Cancel = true;
}
}
else if ((nowUtc - validFrom).TotalMinutes >= halfSpan)
{
SessionSecurityToken renewToken = sam.CreateSessionSecurityToken(
token.ClaimsPrincipal,
token.Context,
nowUtc,
nowUtc.AddMinutes(totalMinutes),
true);
e.SessionToken = renewToken;
e.ReissueCookie = true;
//db timestamp update
}
}
And SignedIn event
public void WSFederationAuthenticationModuleSignedIn(object sender, EventArgs e)
{
token = gettoken from cookie
if (token.ValidTo > DateTime.Now.ToUniversalTime())
{
//db insert for new login (assuming this will fire only once on actual login)
reissue token
}
}
Session timeout is mentioned in the my relying party application web config
<securityTokenHandlers>
<add type="Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
<sessionTokenRequirement lifetime="0:02" />
</add>
</securityTokenHandlers>
Token Life time on ADFS I do not want to change which is greater than 2 minutes.
But issue is, after 2 minutes time out is not happening. It goes to SingedIn event becuase i assume it reissue token and then it calls session token received event so this condition (if (validTo < nowUtc)) never satisfy, how can i achieve timeout here? Freshness="0"achieves it but If i set Freshness="0" then I can not get authenticated by other website which are on same ADFS server. I want to be authenticated on other website as well if i have logged in one.
If I remove freshness="0" I can be authenticated without login on second website which is different application.
Why SignedIn is getting called before session token received and How can i achieve timeout in proper way and get authenticated in multiple website?
Note: I have these events in my customeHttpHanlder module. which has other event as well like PostAuthenticateRequest.

when you receive a session token, the token you receive from adfs starts expiring. After it has been completely expired it needs to be refreshed.
This is a balance between having acurate information from adfs (calling into ad each time you want to know something about the user) and having a workable situation (a signed token has a certain validity in which we trust the information to remain valid).
After the token expires, you need to get back to adfs (hence the signin event) to get a new token from adfs. The idea is that some of the information might have changed between the issuing of these two tokens.
You can implement sliding sessions on the client side (your relying parties) but that makes little sense (I'll come back to this) since you are telling yourself that the token is valid for another period. You trust yourself but the information inside the token can get out of sync and that is why you always need to go back to adfs.
All of this could make sense if you implement an automatic refresh of the token yourself. This would mean that you exchange your current token for a new one with a new validity period. I guess adfs can do this (but you need the active scenario for this). It's not a lot of code but it can be hell to setup right and I don't have any example for this.
In the end you need to ask yourself if it's worth the hassle. WIF will do an automatic signin again and a user inside the domain will be automatically logged in. A user outside the domain might have to type here credentials again. I don't think this is the end of the world.
Finally, I see you use Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler which is the old implementation. .Net 4.5 has a newer implementation..

Windows identity foundation - sign out or update claims

I am using Windows Identity foundation to manage login to our site.
When a user logs in i am using some information in his request to put into the claims.
It is all working fine, but now I need to manage this scenario:
user is already logged in, athenticated and has a valid token.
But user decides to browses in again (via a redirect from another site)
So his information in his request is different.
I want to either
Sign him out - so that he naturally creates a new token with his new information
OR update his existing token.
So my question is:
How do i Sign out of Windows Identity foundation?
Or How do I update the existing claims?
I have tried this code:
public void ExpireClaims(HttpContextBase httpContextBase)
{
var module =
httpContextBase.ApplicationInstance.Modules["WSFederationAuthenticationModule"] as
WSFederationAuthenticationModule;
if (module == null)
{
return;
}
module.SignOut(true);
}
But module is alway null.
and i tried this:
public void FederatedSignOut(string replyUrl)
{
WSFederationAuthenticationModule.FederatedSignOut(null, new Uri(replyUrl));
}
But i get a null reference execption when i do this.
Thanks very much.

Essentially sign-out is just deleting the cookie so:
FormsAuthentication.SignOut
or
FederatedAuthentication.SessionAuthenticationModule.SignOut
or
FederatedAuthentication.SessionAuthenticationModule.DeleteSessionTokenCookie
will work.
Or use the FederatedPassiveSignInStatus (should be in your Toolbox). Set the property SignOutAction to FederatedSignOut and the control will clear out your STS session as well.