DynamoDB Session State & Authentication in ServiceStack 4.0.32

Question

This is a two part issue that resolves around a single objective: Get DynamoDB to work with ServiceStack (particularly, as a Session State Provider, and as an Authentication Provider).

..:: Requirements ::..

What I must do:

1. Use DynamoDB for Session & Credentials Management (an ASP.NET Identity 2.0 implementation)
2. Use ServiceStack 4.0.32 Authentication for 3rd party Federation Identity support
3. Get everything to work on a single web server (either in parallel or co-operatively)

What I have:

• Amazon Web Services DLL for Session Management (DynamoDBSessionStoreProvider)
• Custom ASP.NET Identity 2.0 Implementation for DynamoDB
• ServiceStack 4.0.32 license and working example of 3rd party Federation

..:: Session State ::..

I am using a DynamoDBSessionStoreProvider as per the Amazon Documentation.

This works fine as a web.Config solution until I try to use it with Service Stack, which wires Session Providers up in code:

Plugins.Add(new AuthFeature(() => new CustomUserSession(),
                new IAuthProvider[] {
                    new CredentialsAuthProvider(appSettings),  
                    new BasicAuthProvider(appSettings)
            }));

I understand that CustomUserSession should inherit from AuthUserSession and override methods of interest as indicated in the ServiceStack SocialBootstrapAPI documentation, but first I tried to access the DynamoDBSessionStateStore directly:

Plugins.Add(new AuthFeature(
                () => new DynamoDBSessionStateStore(),
                new IAuthProvider[] { 
                    new CredentialsAuthProvider(appSettings), 
                    new BasicAuthProvider()
            }));

Obviously, this is an issue since DynamoDBSessionStateStore does not implement ServiceStack's IAuthProvider nor inherit from their AuthUserSession concrete implementation. However, this is ultimately what I want.

So, I'm now back to my CustomUserSession, which extends AuthUserSession, but I am having issues getting exposure of DynamoDBSessionStateStore in the way ServiceStack expects.

What is going on is that ServiceStack is creating its own session cookies ss-pid while the custom session provider I've developed is using the .NET Identity session. So, my question is this; given the latest ServiceStack 4.0.32 updates, should I conform my custom provider to use ss-pid or should I somehow get ServiceStack to recognize my custom provider via implementation of AuthUserSession?

..:: Authentication ::..

I am using a custom ASP.NET Identity 2.0 implementation (a full Microsoft.AspNet.Identity implementation) for DynamoDB based strongly on this project found on codeplex. I've made a number of alterations, but the core is basically the same.

The implementation makes use of the IdentityUser, IdentityRole, IdentityUserClaim, and IdentityCloudContext, etc. portions of Identity 2.0 and wraps them into a UserStore and RoleStore.

My question is mostly in regards to the ServiceStack 4.0.32 updates. How should I get these two elements to play together? How can I make the UserStore and RoleStore play nice with ServiceStack Authentication? Implement a series of IAuthProviders?

Perhaps @mythz or someone else in the ServiceStack community will make use of the same DynamoDB ASP.NET Identity 2.0 implementation to start a collective (ServiceStack sanctioned) development project path that we all can agree on and contribute to.

Answer 1

The DynamoDBSessionStateStore is not compatible with AuthUserSession in functionality or concept.

AuthUserSession is just your typed Custom User Session, i.e. predominantly a POCO that gets stored in your preferred Caching Provider. One of the Caching providers available is ServiceStack.Caching.AwsDynamoDb, but this just takes care of serializing the users Session into AWS DynamoDb, i.e. AuthUserSession doesn't provide authentication itself or even take care of where or how to serialize your Session, just what to serialize, as such it should remain a plain-old Data object (POCO).

The relevant moving parts in ServiceStack Authentication are the Auth Providers which take care of how to Authenticate that by default will access the configured Auth Repository where User Auth Info is typically persisted. Once authenticated an instance of the AuthUserSession is created for the authenticated user which is stored with the registered ICacheClient Caching Provider.

Customizing User Roles and Permissions

The default implementation of User Roles and Permissions on AuthUserSession shows how ServiceStack's [RequiredRole] and [RequiredPermission] Roles and Permission attributes are validated:

public virtual bool HasPermission(string permission)
{
    var managesRoles = HostContext.TryResolve<IAuthRepository>() as IManageRoles;
    if (managesRoles != null)
    {
        return managesRoles.HasPermission(this.UserAuthId, permission);
    }

    return this.Permissions != null && this.Permissions.Contains(permission);
}

public virtual bool HasRole(string role)
{
    var managesRoles = HostContext.TryResolve<IAuthRepository>() as IManageRoles;
    if (managesRoles != null)
    {
        return managesRoles.HasRole(this.UserAuthId, role);
    }

    return this.Roles != null && this.Roles.Contains(role);
}

These APIs are virtual so they can be overridden in both your Custom AuthUserSession but they default to looking at the Roles and Permissions collections stored on the Session. These collections are normally sourced from the AuthUserRepository when persisting the UserAuth and UserAuthDetails POCO's and are used to populate the UserAuthSession on successful Authentication. These collections can be further customized by AuthProviders which is what AspNetWindowsAuthProvider does to add Authenticated WindowsAuth Roles.

As seen above Roles/Permissions can instead be managed by AuthProviders that implement IManageRoles API which is what OrmLiteAuthProvider uses to look at distinct RDBMS tables to validate Roles/Permissions.

AWS Support

The missing piece for an AWS backed Authentication is an DynamoDB-based UserAuthRepository. A ServiceStack.AmazonWebServices placeholder repository has been created to store the necessary functionality. Filling in the missing pieces for AWS is on our TODO list but due to lower demand it's currently a lower priority.

One thing to note is that ServiceStack Authentication only includes functionality and filter attributes for Roles/Permissions. Any additional functionality like User Claims would need to be implemented with Custom logic added to ServiceStack's customizable Request Pipeline.