claims-based-identity

I'm using the Thinktecture.IdentityServer.v2 app to perform SSO for a couple of internal apps but would like to customize the login page for each application to have a smoother user experience. I can't seem to find a way to do that. Can the login page be customized depending on the source application from where the client is comming? "I can't seem to find a way to do that." - How hard have you tried? ;) The RP has the extra data fields - so you can hang like a CSS name off the RP in the registration database. Further you can get to that RP data from the signin page - quoting the comment in

How can I test this code (Login method in a ASP.NET MVC 4, .NET 4.5 web app): public ActionResult Login(LoginModel model, string returnUrl) { if (ModelState.IsValid && _userCredentialsService.ValidateUser(model.UserName, model.Password)) { SessionAuthentication.SetAuthCookie(model.UserName, _userCredentialsService.GetUserGroups(model.UserName), model.RememberMe); return RedirectToLocal(returnUrl); } } that uses this SetAuthCookie method: public static void SetAuthCookie(IEnumerable<Claim> claims, bool isPersistent) { if (!HttpContext.Current.Request.IsSecureConnection && FormsAuthentication

I'm trying to understand ASP.NET Identity authentication and authorization mechanics. I understood what's a claim & what's a role. In almost every related blog post, or question on here it's advised to use claims and avoid roles. I'm confused at this point. How can I use claims without roles? (I normally assign roles to users after they are registered. ) Any help is appreciated. Thank you Roles are claims too, claims are just more general. In almost every related blog post, or question on here it's advised to use claims and avoid roles. I can only speculate, as you don't show exact links, that

I am working on a single page application using AngularJS and ASP.NET Identity 2. I log the user in and the cookie is set; however, when I check the Identity of the user on the same request, it shows it as blank and IsAuthenticated is false. However, these are populated on subsequent requests. I was hoping to send back to the UI whether or not the user was logged in on the same request. Is this possible? Code as requested (AngularJS makes AJAX post into WebAPI controller Login method) [HttpPost] [AllowAnonymous] [Route("Login")] public async Task<IHttpActionResult> Login(LoginModel loginModel)

Is it possible with an Owin Middleware implementation to add claims prior to the execution of a Web API controller? Created an OwinMiddleware implementation and added an identity: var id = new ClaimsIdentity(); id.AddClaim(new Claim("Whatever", "is possible")); context.Authentication.User.AddIdentity(id); await Next.Invoke(context); However, even this Invoke method call the identities are not updated (just the internal claims array). And the controller when executed of course never gets the new dummy claim. Ideas? You may find useful inheriting from Authorizate Attribute and extending it to

I'm using ASP.NET Identity 2.2. I'm migrating the ASP.NET old membership to new Identity system. I am following the steps mentioned in this article for performing the migration. I have extended IdentityUser and added few more properties like follows: public partial class AspNetUser : IdentityUser { public AspNetUser() { CreateDate = DateTime.Now; IsApproved = false; LastLoginDate = DateTime.Now; LastActivityDate = DateTime.Now; LastPasswordChangedDate = DateTime.Now; LastLockoutDate = DateTime.Parse("1/1/1754"); FailedPasswordAnswerAttemptWindowStart = DateTime.Parse("1/1/1754");

Azure's ACS service is pretty sweet, and I love all of the magic it can do, but I want a little less magic for my Web app (MVC). If you look at the code samples on CodePlex, it's easy enough to call the service and get a JSON list of login providers from an endpoint like this: https://.accesscontrol.windows.net/v2/metadata/IdentityProviders.js?protocol=wsfederation&realm=http%3a%2f%2flocalhost%3a7070%2f&version=1.0&callback=? From the resulting JSON, you can render some links to the providers, and once you deal with those logins, they'll bounce you back through ACS, and ACS will do a post with