We Keep Coding

Windows Authentication with IdentityServer4 on IIS

I am trying to use Windows Authentication credentials to connect with my native (Winforms, console app) client to Identity Server hosted on IIS. The point is for user to be authenticated by AD and with those credentials get the right claims and roles from the Identity Server (which is run through commercial https://commercial.abp.io/ platform).
EDIT:
I found out it is not client related issue since i cannot use my External login (Windows credentials) even directly on hosted site.
The thing worked locally while hosted by IISExpress, then i published it to IIS and enabled the Anonymous and Windows Authentication in the IIS settings and here is where problems began.
When i run it and click the External Login (Windows Credentials) button i usually get a redirect to https://myserver/Error?httpStatusCode=401
and i get prompt for my windows credentials (which even if i insert correctly, just repeat prompt again).
From time to time i get logged in with my Windows credentials (which is the goal). Login with username and password works fine.
I saw the similar issue mentioned by someone here:
https://github.com/IdentityServer/IdentityServer4/issues/4937 without any solution\answer.
My client is basically the sample NativeConsolePKCEClient from this https://github.com/damienbod/AspNetCoreWindowsAuth
static string _authority = "https://myserver/";
string redirectUri = "https://127.0.0.1:45656";
var options = new OidcClientOptions
{
Authority = _authority,
ClientId = "native.code",
ClientSecret = "secret",
RedirectUri = redirectUri,
Scope = "openid profile",
FilterClaims = false,
Browser = browser,
Flow = OidcClientOptions.AuthenticationFlow.AuthorizationCode,
ResponseMode = OidcClientOptions.AuthorizeResponseMode.Redirect,
LoadProfile = true
};
_oidcClient = new OidcClient(options);
var result = await _oidcClient.LoginAsync();
and on server side the startup configuration services:
private void ConfigureAuthentication(ServiceConfigurationContext context, IConfiguration configuration)
{
context.Services.Configure<IISOptions>(iis => // IISOptions
{
iis.AuthenticationDisplayName = "Windows";
iis.AutomaticAuthentication = false;
});
context.Services.AddAuthentication()
.AddJwtBearer(options =>
{
options.Authority = configuration["AuthServer:Authority"];
options.RequireHttpsMetadata = Convert.ToBoolean(configuration["AuthServer:RequireHttpsMetadata"]); ;
options.Audience = "ABPIdentityServer";
});
}
Here is the ProcessWindowsLoginAsync challenge method:
private async Task<IActionResult> ProcessWindowsLoginAsync(string returnUrl)
{
// see if windows auth has already been requested and succeeded
var result = await HttpContext.AuthenticateAsync(Microsoft.AspNetCore.Server.IISIntegration.IISDefaults.AuthenticationScheme);
if (result?.Principal is WindowsPrincipal wp)
{
// we will issue the external cookie and then redirect the
// user back to the external callback, in essence, tresting windows
// auth the same as any other external authentication mechanism
var props = new AuthenticationProperties()
{
RedirectUri = "./ExternalLoginCallback",
Items =
{
{ "returnUrl", returnUrl },
{ "scheme", Microsoft.AspNetCore.Server.IISIntegration.IISDefaults.AuthenticationScheme },
}
};
var id = new ClaimsIdentity(Microsoft.AspNetCore.Server.IISIntegration.IISDefaults.AuthenticationScheme);
id.AddClaim(new Claim(JwtClaimTypes.Subject, wp.Identity.Name));
id.AddClaim(new Claim(JwtClaimTypes.Name, wp.Identity.Name));
// add the groups as claims -- be careful if the number of groups is too large
{
var wi = (WindowsIdentity)wp.Identity;
var groups = wi.Groups.Translate(typeof(NTAccount));
var roles = groups.Select(x => new Claim(JwtClaimTypes.Role, x.Value));
id.AddClaims(roles);
}
await HttpContext.SignInAsync(IdentityConstants.ExternalScheme, new ClaimsPrincipal(id), props);
return Redirect(props.RedirectUri);
}
else
{
// trigger windows auth
// since windows auth don't support the redirect uri,
// this URL is re-triggered when we call challenge
return Challenge("Windows");
}
}
I am suspecting that this piece of code when calling Challenge somehow returns up redirecting to error page, but i am not sure and i do now why.
So what am i missing? Is it even possible to run both Windows and Anonymous authentication on IIS?
Here i also found similar issue:
identity server 4 windows authentication
but the presented answers did not help me.

I strongly suspect that it's not the client issue it's the token provider's issue (Not the ID4 library but one where you have installed the ID4 library).
I believe that you have added the below code in the AccountController->Login action but make sure that you have added a success check in it, if you miss that then your app will go infinite loop.
[HttpGet] public async Task<IActionResult> Login(string returnUrl)
{
if(loginViewModel.ExternalLoginScheme == "Windows")
{
var authenticationResult = await HttpContext.AuthenticateAsync("Windows").ConfigureAwait(false);
if (authenticationResult.Succeeded && authenticationResult?.Principal is WindowsPrincipal windowsPrinciple)
{
// Add your custom code here
var authProps = new AuthenticationProperties()
{
RedirectUri = Url.Action("Callback"),
Items =
{
{ "returnUrl", returnUrl },
{ "scheme", "Windows"},
}
};
await HttpContext.SignInAsync();
return Redirect(RedirectUri);
}
else
{
return Challenge("Windows");
}
}
}
I hope this will help you to fix your issue.
Happy Coding!!

Just for anybody who might be interested. I found out what was causing the redirect error.
It is somehow connected with the ABP Suite i used for generating the base application.
there in the ApplicationInitialization there was a middleware called
app.UseErrorPage();
Which when the Windows credentials were challenged took it as an Error and redirected to https://myserver/Error?httpStatusCode=401.
I am not sure how this middleware works and why sometimes login worked, but removing this part solved my issue.
I hope this helps somebody, somehow, sometime..

Google Calendar returning invalid grant

I have a customer that is trying to access their calendars from our web application. Everything works for all of our other customers, so I am not sure what is different here except this customer is in Australia and using a non gmail.com email address.
The customer is able to authorize our application and we do get a oauth token for the user. We request calendar access and the customer granted it. When we request a list of all of the calendars, we get the invalid grant message.
Below is the code that we use to access their calendars. The method being called is GetAllWritableCalendars.
public class GoogleCalendarAdapter : ICalendarAdapter {
#region attributes
private readonly ISiteAuthTokenQueryRepository _tokenRepo;
private readonly GoogleCalendarSettings _settings;
private const string APPNAME = "SomeAppName";
private const string ACL_OWNER = "owner";
private const string ACL_WRITER = "writer";
#endregion
#region ctor
public GoogleCalendarAdapter(ISiteAuthTokenQueryRepository tokenRepo,
GoogleCalendarSettings settings) {
_tokenRepo = tokenRepo;
_settings = settings;
}
#endregion
#region methods
private GoogleAuthorizationCodeFlow BuildAuthorizationCodeFlow() {
return new GoogleAuthorizationCodeFlow(new GoogleAuthorizationCodeFlow.Initializer() {
ClientSecrets = BuildClientSecrets(),
Scopes = BuildScopeList()
});
}
private CalendarService BuildCalendarService(SiteAuthToken token) {
return new CalendarService(new BaseClientService.Initializer() {
ApplicationName = APPNAME,
HttpClientInitializer = BuildUserCredential(token)
});
}
private ClientSecrets BuildClientSecrets() {
return new ClientSecrets() {
ClientId = _settings.ClientId,
ClientSecret = _settings.ClientSecret
};
}
private string[] BuildScopeList() {
return new [] { CalendarService.Scope.Calendar };
}
private UserCredential BuildUserCredential(SiteAuthToken token) {
TokenResponse responseToken = new TokenResponse() {
AccessToken = token.AccessToken,
RefreshToken = token.RefreshToken
};
return new UserCredential(BuildAuthorizationCodeFlow(), APPNAME, responseToken);
}
public async Task<List<Cal>> GetAllWritableCalendars(Guid siteGuid) {
SiteAuthToken token = await GetToken(siteGuid);
CalendarService svc = BuildCalendarService(token);
IList<CalendarListEntry> calendars = svc.CalendarList
.List()
.Execute()
.Items;
return calendars.Where(c => c.AccessRole.Equals(ACL_OWNER, StringComparison.CurrentCultureIgnoreCase) ||
c.AccessRole.Equals(ACL_WRITER, StringComparison.CurrentCultureIgnoreCase))
.Select(c => new Cal() {
Id = c.Id,
Name = c.Summary
})
.OrderBy(o => o.Name)
.ToList();
}
private async Task<SiteAuthToken> GetToken(Guid siteGuid) {
SiteAuthToken retVal = await _tokenRepo.GetSiteAuthToken(siteGuid);
if (retVal == null) {
throw new ApplicationException($"Could not find a SiteAuthToken for specified site (SiteGuid: {siteGuid})");
}
return retVal;
}
#endregion

The credentials are the authorization from Google to Your Application to use the scopes you have set-up, this is okay to have it in a database if you update it every time you add new scopes to your app.
The Access Token is the authorization from the user to your application to get it's Google Data (calendar in this case). It has a limited lifetime so this is not okay to save in a database.
The Refresh Token is the token that allows your application to get more tokens for a client. It has a limited lifetime as well.
For more info see: Using OAuth 2.0 to Access Google APIs
Every time you change your scopes or add more scopes you have to re-generate the credentials. You have 50 refresh tokens per user account per client, see Token expiration. So having the tokens in a database makes no sense since they are going to get deprecated at some point, if you have 51 clients the 1st token will get deprecated.
Check:
How do you have it set-up on your database
If you renew properly the tokens
If you are using the correct tokens for the users
You can delete all the tokens (NOT the CREDENTIALS) and your current users will only have to go through the consent screen and allow it again, they will not lose the connection.

I asked the question later in a different way. Maybe it was a little more relevant. Perhaps there was a little more information available. What ever the case may be, I discovered how to test things properly.
Look at this question

SSO Sustainsys.Saml2.Owin Request is not Authenticated - access_denied

I have to do SSO authentication with saml2 for my existing asp.net web application.
I am using Sustainsys.Saml2.Owin example to do that.
Identity provider is Azure ADFS ( https://sts.windows.net/TENANTID )
I have configured the Startup file. It loads the metadata file and certificate.
And in my Login page, I am challenging if not authenticated.
It is successfully redirecting to the login page but the Request is never getting authenticated after the login. And in the reply URL we are getting error=access_denied
[neither Request.IsAuthenticated or owinContext.Authentication.User.Identity.IsAuthenticated is set to true]
So it keep on challenging for many times and error with bad request.
What I am doing wrong?
Which module of Owin/Sustainsys is reposnsible to set the IsAuthenticated status?
*a Saml2. cookie [Saml2.DAeP63c***UTX0h***_***] is passed along with the request after login into Microsoft [https://login.microsoftonline.com/TENANTID/saml2]
Startup.cs file
public void ConfigureAuth(IAppBuilder appBuilder)
{
try
{
appBuilder.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
appBuilder.UseCookieAuthentication(new CookieAuthenticationOptions());
appBuilder.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
appBuilder.UseSaml2Authentication(CreateSaml2Options());
}
catch (Exception exp)
{
}
}
private Saml2AuthenticationOptions CreateSaml2Options()
{
try
{
var spOptions = CreateSPOptions();
var Saml2AuthOptions = new Saml2AuthenticationOptions(false)
{
SPOptions = spOptions,
Notifications = new Saml2Notifications(),
};
var idp = new IdentityProvider(new EntityId(authority), spOptions)
{
MetadataLocation = metadataLocation,
Binding = Saml2BindingType.HttpRedirect
};
idp.SigningKeys.AddConfiguredKey(
new X509Certificate2(certificateLocation));
Saml2AuthOptions.IdentityProviders.Add(idp);
return Saml2AuthOptions;
}
catch (Exception exp)
{
}
}
private SPOptions CreateSPOptions()
{
try
{
var engAus = "en-AU";
var organization = new Organization();
var spOptions = new SPOptions
{
EntityId = new EntityId(ApplicationId),
ReturnUrl = new Uri(redirectUrl),
Organization = organization,
};
return spOptions;
}
catch (Exception exp)
{
}
}
Login.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
IOwinContext owinContext = HttpContext.Current.GetOwinContext();
//if (Request.IsAuthenticated)
if (owinContext.Authentication.User != null &&
owinContext.Authentication.User.Identity != null &&
owinContext.Authentication.User.Identity.IsAuthenticated)
{
//Authenticated
string name = owinContext.Authentication.User.Identity.Name;
}
else
{
var authenticationTypes = owinContext.Authentication.GetAuthenticationTypes().Select(d => d.AuthenticationType).ToArray();
owinContext.Authentication.Challenge(new AuthenticationProperties { RedirectUri = "/" }, authenticationTypes);
}
}
}

(all code posted here are the same sample from Github)
You need to understand how SAML works, here's a simple saml implementation class that I used before I dive into SustainsysSAML. AspNetSaml
This is the basic flow of SAML Implementation:
User access your app, if user is not yet authenticated your app should redirect the user to your saml provider.
//specify the SAML provider url here, aka "Endpoint"
var samlEndpoint = "http://saml-provider-that-we-use.com/login/";
var request = new AuthRequest(
"http://www.myapp.com", //put your app's "unique ID" here
"http://www.myapp.com/SamlConsume" //assertion Consumer Url - the redirect URL where the provider will send authenticated users
);
//generate the provider URL
string url = request.GetRedirectUrl(samlEndpoint);
//then redirect your user to the above "url" var
//for example, like this:
Response.Redirect(url);
From saml provider, user enters credentials and if valid user, saml provider will authenticate and redirect the user to your app.
SAML provider will post the samlresponse to your app (eg. http://www.myapp.com/SamlConsum).
//ASP.NET MVC action method... But you can easily modify the code for Web-forms etc.
public ActionResult SamlConsume()
{
//specify the certificate that your SAML provider has given to you
string samlCertificate = #"-----BEGIN CERTIFICATE-----
BLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAHBLAH123543==
-----END CERTIFICATE-----";
Saml.Response samlResponse = new Response(samlCertificate);
samlResponse.LoadXmlFromBase64(Request.Form["SAMLResponse"]); //SAML providers usually POST the data into this var
if (samlResponse.IsValid())
{
//WOOHOO!!! user is logged in
//YAY!
//Some more optional stuff for you
//lets extract username/firstname etc
string username, email, firstname, lastname;
try
{
username = samlResponse.GetNameID();
email = samlResponse.GetEmail();
firstname = samlResponse.GetFirstName();
lastname = samlResponse.GetLastName();
}
catch(Exception ex)
{
//insert error handling code
//no, really, please do
return null;
}
//user has been authenticated, put your code here, like set a cookie or something...
//or call FormsAuthentication.SetAuthCookie() or something
}
}
Your app will read the samlresponse and if valid will let the user use your app, your app will now handle the roles of the user depending on your policies.
Some tips:
Make sure your app is identifiable by your saml provider.
Use Firebug to trace your http requests (or any http tracing tool)
Understand the difference between samlresponse and samlrequest
Using Firebug you should be able to see the samlresponse.
If you have multiple web apps that you want to have SSO using your saml provider. I suggest you create an httprequest/httphandler to handle the samlresponse from your provider. You can then install this dll to your server and just add the handler to each web app's config. No code change require to your web apps :).
I hope this helps.

ASP.NET Identity WebAPI invalid password reset token

I have a Webapi service that generates the password Reset token.
Token generation service end point:
[Authorize(Users = "abcd")]
[HttpGet]
[ActionName("GenerateForgotPasswordToken")]
public async Task<IHttpActionResult> GenerateForgotPasswordToken(string key)
{
if (key == null || UserManager.FindById(key) == null)
{
return InternalServerError(new Exception("User not found"));
}
return Ok(await UserManager.GeneratePasswordResetTokenAsync(key));
}
My application UserManager:
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
//var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));
var manager = new ApplicationUserManager(new UserStore<IdentityUser>(new MTA()));
// Configure validation logic for usernames
manager.UserValidator = new UserValidator<IdentityUser>(manager)
{
AllowOnlyAlphanumericUserNames = false,
RequireUniqueEmail = true
};
// Configure validation logic for passwords
manager.PasswordValidator = new PasswordValidator
{
RequiredLength = 6,
RequireNonLetterOrDigit = true,
RequireDigit = true,
RequireLowercase = true,
RequireUppercase = true,
};
var dataProtectionProvider = options.DataProtectionProvider;
if (dataProtectionProvider != null)
{
manager.UserTokenProvider = new DataProtectorTokenProvider<IdentityUser>(dataProtectionProvider.Create("ASP.NET Identity"));
}
return manager;
}
The token will be used in an email to send a password reset URL to the user. That URL points to an ASP.NET MVC view which is part of my WebAPI project and obviously is hosted in the same web application in IIS. The password reset button on the page calls my other service endpoint which resets the password.
Passowrd reset service end point:
[HttpGet]
[AllowAnonymous]
public async Task<HttpResponseMessage> ResetPassword([FromUri]string email,[FromUri]string code,[FromUri]string password)
{
var user = await UserManager.FindByEmailAsync(email);
var result = await UserManager.ResetPasswordAsync(user.Id, code, password);
if (result.Succeeded)
{
return Request.CreateResponse();
}
return Request.CreateResponse(System.Net.HttpStatusCode.Ambiguous);
}
Also it might help to mention that both those web api endpoints are in the same controller and in the controller I defined a global UserManger as follows:
private ApplicationUserManager _userManager;
public ApplicationUserManager UserManager
{
get
{
return _userManager ?? Request.GetOwinContext().GetUserManager<ApplicationUserManager>();
}
private set
{
_userManager = value;
}
}
When I use an external tool like Advanced REST Client, I am able to hit the first endpoint to generate the token and then pass the token to the second endpoint along with email and new password and successfully reset the password. However when my ASP.NET MVC controller uses the same token generated by the first endpoint and call the passwordReset endpoint , the token is invalid! I already make sure that the is no Encoding/Decoding issue and the token that is received by the second end point is identical in both tests.
Once again all my WebApi and ASP controllers are in the same project and hosted in the same web application.
I think the problem might be related to having a new Token provider when a request is comming based on the OwinContext but I don't understand why it works calling it through web browser.
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)

I found the problem after reading this question:
Make ASP.NET Identity 2.0 Email confirm token work for WCF and MVC
In my case IIS was configured to generate the Machine Key at runtime and that's why the token was invalid even when all my code was running as a single application.
Here is a guide to IIS machine key configuration :How to Generate Machine Key using IIS

Reconnecting to Servicestack session in an asp.net MVC4 application

I have an asp.net mvc4 web application that is consuming data data from an API written in C# and hosted on a Linux machine w/ Apache / mod_mono
The client application is written in C#/asp.net - It runs on a different web server, also Linux / Apache / mod_mono. I'm not sure if those details are important in this case, but I figured any background may help.
The question leading up to this one: AppHostBase instance not set - Helped me gain quite a bit more understanding of how this all fits together.
I believe the proper question I should be asking now is: Once I create a session in servicestack (On the API server), how do I properly reconnect to it?
Following the answers in previous questions, I've used this bit of code in my auth controller on the client application:
var authService = AppHostBase.Resolve<AuthService>();
authService.RequestContext = System.Web.HttpContext.Current.ToRequestContext();
var AuthResponse = authService.Authenticate(new Auth
{
provider = "credentials",
UserName = user.user_id,
Password = user.password,
RememberMe = true
});
This returns a ResolutionException:
Required dependency of type ServiceStack.ServiceInterface.Auth.AuthService could not be resolved.
Is there something simple I might be missing when it comes to getting the client to work from within an asp.net application?
I apologize if the question is too vague and will happily provide any more information.
Update:
This is AuthController - Excuse the mess, I've been trying a few things since my last post:
{
public partial class AuthController : BaseController
{
JsonServiceClient client = new ServiceStack.ServiceClient.Web.JsonServiceClient("<TheAPIurl>");
// GET: /Login/
public ActionResult login()
{
if (Session["IsAuthenticated"] != null)
{
ViewData["Result"] = Session["IsAuthenticated"];
}
return View();
}
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult login(UserModel user)
{
try
{
var authService = AppHostBase.Resolve<AuthService>();
authService.RequestContext = System.Web.HttpContext.Current.ToRequestContext();
var AuthResponse = authService.Authenticate(new Auth
{
provider = "credentials",
UserName = user.user_id,
Password = user.password,
RememberMe = true
});
if (AuthResponse.SessionId != null)
{
Session["IsAuthenticated"] = true;
Session["UserID"] = AuthResponse.UserName;
Session["jsclient"] = client;
FormsAuthentication.SetAuthCookie(user.user_id, true);
return Redirect("/default");
}
else
{
Session["IsAuthenticated"] = false;
}
}
catch (Exception ex)
{
Session["IsAuthenticated"] = false;
}
return View();
}
protected override void ExecuteCore()
{
throw new NotImplementedException();
}
}
}

Authenticating with a local ServiceStack instance
You can only retrieve an auto-wired ServiceStack service (or other IOC dependency) out from a ServiceStack Container if the ServiceStack instance is hosted within the same App Domain as MVC, i.e:
var authService = AppHostBase.Resolve<AuthService>();
authService.RequestContext = System.Web.HttpContext.Current.ToRequestContext();
Although the recommended code for resolving the auto-wired implementation of another service is:
using (var authAservice = AppHostBase.ResolveService<AuthService>()) {
...
}
i.e. As services may make use of resources that should be disposed. Inside a ServiceStack service you should use base.ResolveService<AuthService>() instead.
So if ServiceStack hosted within the same AppDomain as MVC, you can call the Service directory, like this:
var authResponse = authService.Authenticate(new Auth {
provider = "credentials",
UserName = user.user_id,
Password = user.password,
RememberMe = true
});
Authenticating with a Remote ServiceStack instance
Otherwise if it's remote you need to use one of ServiceStack's C# Service Clients, e.g:
var client = new JsonServiceClient(ServiceStackBaseUrl);
var authResponse = client.Post(new Auth {
provider = "credentials",
UserName = user.user_id,
Password = user.password,
RememberMe = true
});
Attaching ServiceStack SessionId back to originating MVC request
This will setup an authenticated session with that ServiceClient client, by attaching it to the ss-pid Cookie (see Session docs for more info). You can pass through this cookie to the originating browser that called MVC with:
var response = HttpContext.Current.Response.ToResponse();
response.Cookies.AddSessionCookie(
SessionFeature.PermanentSessionId, authResponse.SessionId);
Subsequent requests with the authenticated session
To re-attach with the remote authenticated ServiceStack Session from within MVC you would then need to pass the cookie back into the Service Client, e.g:
var cookie = HttpContext.Request.Cookies.Get(SessionFeature.PermanentSessionId);
var client = new JsonServiceClient(ServiceStackBaseUrl);
var cookie = new Cookie(SessionFeature.PermanentSessionId, cookie.Value);
client.CookieContainer.Add(cookie);
You can set the cookie domain, globally in the Web.Config:
<httpCookies domain="mydomain.com" />
Or at runtime with:
cookie.Domain = "mydomain.com";
The ServiceStack AuthTests.cs Integration Tests has some other useful examples showing how Authentication works in ServiceStack.