Hi Demis, I'm a bit late to the party, but I thought I'd post some feedback here.

- I primarily use this to leverage integrated(Kerberos/Negotiate) authentication from Windows. One early thing I needed do to was map a user's AD groups to ServiceStack Roles. Initially, I extended the LoadUserAuthInfo function to do an AD lookup to groups, then dump the list of groups to the user's AuthUserSession.Roles. This, while a common way people do AD authorization outside of Windows, is a bit expensive because of the LDAP lookup for every auth request. The original IIS request does contain the Kerberos ticket (with the AD groups already burned into the ticket), but I couldn't get the request without subclassing AspNetWindowsAuthProvider:

public class CustomWindowsAuthProvider : AspNetWindowsAuthProvider
{
public CustomWindowsAuthProvider(IAppHost appHost) : base(appHost)
{

}

public override IHttpResult OnAuthenticated(IServiceBase authService, IAuthSession session, IAuthTokens tokens, Dictionary<string, string> authInfo)
{
var request = authService.Request.OriginalRequest as System.Web.HttpRequestWrapper;

using (WindowsIdentity userId = request?.LogonUserIdentity)
{
List<string> roles = new List<string>();
if (userId?.Groups != null)
foreach (var group in userId.Groups)
{
// Remove the domain name from the name of the group, if it has it, and you don't need it.
var groupName = new SecurityIdentifier(group.Value).Translate(typeof(NTAccount)).ToString();
if (groupName.Contains("\\"))
groupName = groupName.Split('\\')[1];
roles.Add(groupName);
}
session.Roles = roles;
}
return base.OnAuthenticated(authService, session, tokens, authInfo);
}

}

It would be nice if something similar to the above was burned into the base AspNetAuthProvider. (I'm not sure if the above works for all scenarios).

- Give the above scenario (IIS with integrated authentication), how does the .NET SSE client authenticate? I didn't see a Credentials property for the SSE client.

@Steve I had some related issues with my users, esp. when they were using IE vs. Chrome. In IIS for the website, I went to "Authentication" module -> Windows Authentication -> Providers (on the right) and changed the order to [ NTLM, Negotiate]

Just to let you know that I am using this feature in production for a couple of months and it is working very nice (while solving a lot of issues that I had when using a ServiceStack v3 based workaround).

I have used this feature and seems to be working ok and fixes all the problems I had with windows authentication and servicestack.
I haven't used it side by side with other authentication method(not sure if even possible).
You can mark the issue as complete from my point of view.

Is there a working example of this in action? I tried to implement this using 4.0.23, and received a bunch of 401s using IIS Express after following the registration code that was included in the release notes. I was trying to go to http://<websiteUrl>/auth/windowsauth, and then I could see that I was authorized at http://<websiteUrl>/auth; however, when I attempted to access one of my services that was tagged with [Authenticate], I'd get a popup in my browser asking for username/pass (and my windows credentials would not work here). Any ideas on what might be missing or going on?

This is the code I was using to enable the feature:
Plugins.Add(new AuthFeature(
() => new AuthUserSession(),
new IAuthProvider[] {
new AspNetWindowsAuthProvider(this) { AllowAllWindowsAuthUsers = true },
}
));

Having AD Auth support without IIS for standalone Windows Services that don't use ASP.net and just provide RESTful web services. Then also to use the creds to pass through to calling Windows API calls, so possible requiing the ability for the Windows Service to impersonate using the AD creds provided at the time of calling the web service.

I'm interested in feedback for the AspNetWindowsAuthProvider that was just added in v4.0.21

https://github.com/ServiceStack/ServiceStack/blob/master/release-notes.md#windows-auth-provider-for-aspnet

It should now let you use [RequiredRole] to protect services for users with different roles (which uses the IPrincipal.IsInRole() API under the hood).

I'm interested in hearing about more specific use-cases that this can be extended to support.

I'm sure this can be implemented with appropriate AD config, but I'd add support for Azure Active Directory as well.