I'm building MVC 5 webapp with Windows Authentication.
Since I have external authorization store, so I want to add some custom claims authentication. I handle the PostAuthenticationRequest event
void Application_PostAuthenticateRequest()
{
if (Request.IsAuthenticated)
{
var id = ClaimsPrincipal.Current.Identities.First();
...
//query authorization store
id.AddClaim(new Claim(ClaimTypes.Role, "SomeRole"));
}
}
Then in controller, I check the IsInRole("SomeRole") , but I found it always return false even the identity have the SomeRole role claim
Then I found out that in Windows Authentication, the IsInRole() is using groupsid claims as role
Instead of add my custom claim to groupsid claim, how can I set the IsInRole function use the standard Role claims?
Look like RoleClaimType is the way to go, but it is readonly I cannot set it.
I don't think you can change the behavior of the WindowsPrincipal.IsInRole method.
What you can do is create a new ClaimsPrincipal from a new ClaimsIdentity, using the claims from the WindowsPrincipal. One of the ClaimsIdentity constructors lets you specify the nameType and roleType.
Having set the new ClaimsPrincipal, your IsInRole calls should work on the specified roleType.
Related
I am having difficulty figuring out how to set the current user in an ASP.NET MVC 5 application that uses ASP.NET Identity.
We use a Web Service that encapsulates authentication. A function calls that service and gets back a JWT token that can be "unwrapped" to retrieve the ClaimsIdentity. It's my understanding that all you should need to do, at that point, is call HttpContext.GetOwinContext().Authentication.SignIn() and pass the ClaimsIdentity to establish the current user and get that user to persist across requests.
However, this doesn't seem to be the case. If I query this.User in the controller or the view afterwards, it's an anonymous user (this.User.Identity.IsAuthenticated evaluates to false). Also, refreshing the page or redirecting makes it obvious that there's no current user (again, this.User.Identity.IsAuthenticated evaluates to false).
When I inspect the identity I've retrieved from AccountHelper, all the data is there. It's fully populated with a name, an ID, and a full suite of claims.
So what is the right way to establish the current user and get it to persist across requests?
// This call authenticates a user with the provided credentials against our user store
// and returns a bearer token and a ClaimsIdentity.
var response = new AccountHelper().AuthenticateUser(credentials);
if (response.IsAuthenticated) // This is true
{
// This comes back with a fully populated identity, as expected.
var claimsIdentity = response.ClaimsIdentity;
// This call has no effect, whatsoever. It doesn't set the current user.
HttpContext.GetOwinContext()
.Authentication
.SignIn(new AuthenticationProperties { IsPersistent = true }, claimsIdentity);
First of all, did you miss .Current in your code sample?
It should be
HttpContext.Current.GetOwinContext()
.Authentication
.SignIn(...);
Secondly, I'm assuming you've setup cookie authentication in your app?
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
...
});
Here setting the authentication type is important! And when you generate the claims identity and before you pass it into the .SignIn() method, the claims identity needs to have the same authentication type so that they can talk!
I would use .CreateIdentityAsync() method from the UserManager class to create the identity instead, because you can pass the authentication type in as one of the parameters:
// Create an application user from your claim identity?
var appUser = new AppUser { ... };
// And pass the user into manager to create the identity with the same authentication
// type you used when you setup the cookie authentication
var claimsIdentity = _userManager.CreateIdentityAsync(appUser,
CookieAuthenticationDefaults.AuthenticationType);
I am using this way to impersonate users for admins that have developer role so that we can test the app.
Is there a way to authenticate a session without creating an ApplicationUser in MVC 5 identity?
For various reasons, I ended up using a two layered authentication system. I parse a "user" object from my custom db into session, and in various places all over the site, the existence of this object is how the logged-in status of a user is determined.
I use Identity user stuff (e.g. claims, logins, etc.) at various places of the site. But at this one specific instance, I need to log in an anonymous Identity user and parse whatever user object is requested to the session. So how can I create an anonymously authenticated session with Identity V2?
In Identity you don't need to have user object to authenticate. You could create some claims on the fly and use them to authenticate. Consider this simple example:
[HttpPost]
public ActionResult AnonymousLogin()
{
var ident = new ClaimsIdentity(
new[]
{
// adding following 2 claim just for supporting default antiforgery provider
new Claim(ClaimTypes.NameIdentifier, "AnonymousUserID"),
new Claim("http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider", "ASP.NET Identity", "http://www.w3.org/2001/XMLSchema#string"),
new Claim(ClaimTypes.Name, "AnonymousUserID"),
},
DefaultAuthenticationTypes.ApplicationCookie);
HttpContext.GetOwinContext().Authentication.SignIn(
new AuthenticationProperties { IsPersistent = false }, ident);
return RedirectToAction("MyAction"); // auth succeed
}
Now you have authenticated an anonymous user just like a real user:
[Authorize]
public ActionResult MyAction()
{
// all authorized users could use this method don't matter how have been authenticated
// you have access current user principal
var username=HttpContext.User.Identity.Name;
}
I'm using ASP.Net Identity with ADFS 2.0 (I think).
Users log in at a separate server, come back to me, I check the ClaimsPrincipal and pull out the userID claim, then use that ID to retrieve the user.
So I'm only using ADFS/claims-based auth to get the user object; after that, I have things like usergroups and roles, but they are custom objects and I manage them in the application rather than using ADFS to manage them.
What I want to know is: How hard is it to use my custom database roles with the out-of-the-box role stuff? Specifically, I want to be able to use the Role("RoleName") attribute on controllers, and wrap some UI elements in User.IsInRole("RoleName") on the views to control user access.
What do I have to do to wire this up?
I'm not aware of any Role attribute. Do you mean Authorize("RoleName") attribute?
Adding a role claim that is compatible with IPrincipal.IsInRole and AuthorizeAttribute as a consequence is very easy. Just add a claim with the type ClaimTypes.Role
//when creating a new identity
var identity = new ClaimsIdentity(new Claim[] {
new Claim(ClaimTypes.Role, "MyRole1"),
new Claim(ClaimTypes.Role, "MyRole2")
});
//add a claim to an identity
identity.AddClaim(new Claim(ClaimTypes.Role, "MyRole3"));
Then in your controller, add the AuthorizeAttribute
Authorize("MyRole1")
I am trying to use a simple custom role provider and using the code from here: http://code.google.com/p/sfckopanka/source/browse/trunk/App_Code/OdbcRoleProvider.cs?r=45
Which is implemented using this: http://msdn.microsoft.com/en-us/library/tksy7hd7(v=vs.100).aspx
This is all just simple boilerplate code from Microsoft.
When I debug my app I can see that my Role Provider is initialized BUT no methods are ever called when I try to check roles.
[Authorize(Roles="Customer")]
or
User.IsInRole("Customer")
I put break points in several places in my role provider and they are just never hit.
FYI I am using WebAPI and I am not using a Membership Provider, instead I am using Basic Auth via a message handler.
http://www.piotrwalat.net/basic-http-authentication-in-asp-net-web-api-using-message-handlers/
The Basic Auth is working great, but I ma not sure if this is what is preventing my Role Provider from being called.
Answering this in case it can help someone else. In the Basi Auth code linked above there there is a PrincipalProvider class. in this class you create a GenericPrincipal, which also takes the roles that the user is in, so I just had to add a line of code to get my roles to provide to the GenericPrincipal
public IPrincipal CreatePrincipal(string username, string password)
{
if (!MyRepo.Authentication.ValidateUser(username, password))
{
return null;
}
var identity = new GenericIdentity(username);
//Code to get my roles from my role provider to use when setting principal
string[] roles =Roles.Provider.GetRolesForUser(username);
IPrincipal principal = new GenericPrincipal(identity,roles);
ShopZioRepo.ClearUserCache(ShopZioGlobal.MyCookies.UserID);
var user = ShopZioRepo.GetUserByEmail(username);
ShopZioGlobal.MyCookies.UserID = user.SalesRepID;
ShopZioGlobal.MyCookies.Username = username;
return principal;
}
Hope this helps someone.
I am developing an MVC 4 Application to be hosted in Azure and want to use their ACS service for authentication. Once the user is authenticated I will use the resulting claim details to correlate to my local records. Subsequent to that, I would like to extend the claimset to include additional claims that represent local authorizations which my application would use for authorization decisions. I assume I need to replace the Principle but I'm not sure where/when to do this in MVC and want to avoid breaking any of the authentication plumbing which would normally be used throughout the life of the session. Can anyone shed some light on this?
The extensibility point in WIF for enriching the claimset is the ClaimsAuthenticationManager
From the docs:
The claims authentication manager provides an extensibility point in
the RP processing pipeline that you can use to filter, modify, or
inject new claims into the set of claims presented by an
IClaimsPrincipal before the RP application is called.
You can also add rules in ACS to enrich the token with the claims you need.
In addition to what #Eugenio Pace has said, it's worth noting that you can just add and remove claims to and from the IClaimsPrincipal:
public static void UpdateClaims(IClaimsIdentity identity)
{
identity.Claims.Remove(identity.Claims.SingleOrDefault(x => x.ClaimType == ClaimTypes.Name));
identity.Claims.Remove(identity.Claims.SingleOrDefault(x => x.ClaimType == ClaimTypes.Email));
identity.Claims.Add(new Claim(ClaimTypes.Name, "Steve Smith"));
identity.Claims.Add(new Claim(ClaimTypes.Email, "steve#smith.com"));
}
UpdateClaims(User.Identity as IClaimsIdentity);
Claims added can either be one of the types enumerated in ClaimTypes, or a custom string of your own devising. You can add multiple claims of type ClaimTypes.Role - I'm not sure about the other types.
From the ClaimsCollection docs:
Represents a collection of claims associated with a single subject.
Adding a Claim to a ClaimCollection implicitly associates that Claim
with the subject associated with the collection by calling the
SetSubject method.
Removing a Claim from a ClaimCollection implicitly removes this
association by also calling the SetSubject method.
http://msdn.microsoft.com/en-us/library/microsoft.identitymodel.claims.claimcollection.aspx
Update
For .Net 4.5, the identity class and the method for updating claims have changed, as well as the namespace:
using System.IdentityModel;
using System.Security.Claims;
public static void UpdateClaims(Member member, ClaimsIdentity identity)
{
identity.RemoveClaim(identity.Claims.SingleOrDefault(x => x.Type == ClaimTypes.Name));
identity.RemoveClaim(identity.Claims.SingleOrDefault(x => x.Type == ClaimTypes.Email));
identity.AddClaim(new Claim(ClaimTypes.Name, "Steve Smith"));
identity.AddClaim(new Claim(ClaimTypes.Email, "steve#smith.com"));
}
UpdateClaims(User.Identity as ClaimsIdentity);
http://msdn.microsoft.com/en-us/library/system.security.claims.claimsidentity.aspx