I suggest you ...

Built-in Active Directory Authentication suport.

I would really like to see out of the box support for IWA - Integrated Windows Authentication with Active Directory. Many in-house .Net developers for both large and small organizations write web applications that are Intranet facing, and require the use of Integrated Windows Authentication with IIS. In these environments, corporate security policy often dictates that Active Directory group membership should drive what resources a user can and cannot access.
So, Kerberos authentication often plays a big part in shipping the logged in user’s credentials via tickets from the application server to back end databases. Built-in support for a ServiceStack web service to be Active Directory aware would be awesome and would simplify implementing this security! We currently use Filter Attributes to get this desired behavior for our ServiceStack web services but would love to see this important part of security built in to the stack to simplify integration.
Jeff Ronay – Cleveland, Ohio

155 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Jeff Ronay shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
  • Julian Rodriguez commented  ·   ·  Flag as inappropriate

    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];
    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.

  • Johann Klemmack commented  ·   ·  Flag as inappropriate

    @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]

  • Alexandru Vasile Pop commented  ·   ·  Flag as inappropriate

    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).

  • Alexandru Vasile Pop commented  ·   ·  Flag as inappropriate

    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.

  • Steve Van Treeck commented  ·   ·  Flag as inappropriate

    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 },

  • Rodney S. Foley commented  ·   ·  Flag as inappropriate

    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.

  • AdminDemis J Bellot (Developer, ServiceStack) commented  ·   ·  Flag as inappropriate

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


    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.

Feedback and Knowledge Base