Question

这是一个解决单一目标的两部分问题：让DynamoDB与ServiceStack一起使用（特别是，作为会话状态提供程序，以及作为身份验证提供程序）。

.. :: Requirements :: ..

我必须做的事情：

使用DynamoDB进行会话＆amp;凭据管理（ASP.NET Identity 2.0实现）
使用ServiceStack 4.0.32身份验证进行第三方联合身份验证支持
让所有内容在单个Web服务器上运行（并行或协作）

我有什么：

用于会话管理的Amazon Web Services DLL（DynamoDBSessionStoreProvider）
DynamoDB的自定义ASP.NET Identity 2.0实现
ServiceStack 4.0.32许可证和第三方联合会的工作示例

.. ::会话状态:: ..

我正按照Amazon Documentation使用DynamoDBSessionStoreProvider。

这可以很好地用作web.Config解决方案，直到我尝试将它与Service Stack一起使用，它将会话提供程序连接到代码中：

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

我理解CustomUserSession应该从AuthUserSession继承并覆盖ServiceStack SocialBootstrapAPI documentation中指示的感兴趣的方法，但首先我尝试直接访问DynamoDBSessionStateStore：

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

显然，这是一个问题，因为DynamoDBSessionStateStore不实现ServiceStack的IAuthProvider，也不继承其AuthUserSession具体实现。然而，这最终是我想要的。

所以，我现在回到我的CustomUserSession，它扩展了AuthUserSession，但我遇到了以ServiceStack期望的方式暴露DynamoDBSessionStateStore的问题。

当我开发的自定义会话提供程序使用.NET Identity会话时，ServiceStack正在创建自己的会话cookie ss-pid。所以，我的问题是这个;鉴于最新的ServiceStack 4.0.32更新，我是否应该使用自定义提供程序来使用ss-pid，或者我应该通过实现AuthUserSession以某种方式让ServiceStack识别我的自定义提供程序？

.. :: Authentication :: ..

我正在强烈使用codeplex上的this project为DynamoDB使用自定义ASP.NET Identity 2.0实现（完整的Microsoft.AspNet.Identity实现）。我做了很多改动，但核心基本相同。

该实现使用Identity 2.0的IdentityUser，IdentityRole，IdentityUserClaim和IdentityCloudContext等部分，并将它们包装到UserStore和RoleStore中。

我的问题主要是关于ServiceStack 4.0.32更新。我该如何让这两个元素一起玩？如何使UserStore和RoleStore在ServiceStack身份验证中发挥出色？实施一系列IAuthProviders？

也许@mythz或ServiceStack社区中的其他人将使用相同的DynamoDB ASP.NET Identity 2.0实现来启动集体（ServiceStack批准的）开发项目路径，我们都可以就此达成一致并做出贡献。

Answer 1

DynamoDBSessionStateStore在功能或概念上与AuthUserSession不兼容。

AuthUserSession只是您的typed Custom User Session，即主要是POCO，它会存储在您首选的Caching Provider中。其中一个可用的缓存提供程序是ServiceStack.Caching.AwsDynamoDb，但这只是将用户会话序列化为AWS DynamoDb，即AuthUserSession本身不提供身份验证，甚至不需要处理或者如何序列化你的会话，只需来序列化，因此它应该仍然是一个普通的数据对象（POCO）。

ServiceStack Authentication中的相关移动部件是Auth Providers，用于处理如何进行身份验证，默认情况下将访问已配置的Auth Repository用户身份验证信息通常是持久的。经过身份验证后，将为经过身份验证的用户创建AuthUserSession的实例，该实例与已注册的ICacheClient Caching Provider一起存储。

自定义用户角色和权限

AuthUserSession上的用户角色和权限的默认实现显示了ServiceStack [RequiredRole]和[RequiredPermission] Roles and Permission attributes的验证方式：

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);
}

这些API为virtual，因此可以在自定义AuthUserSession中覆盖它们，但它们默认查看会话中存储的Roles和Permissions个集合。这些集合通常来自AuthUserRepository，在UserAuth and UserAuthDetails POCO's持久存储时用于在成功验证时填充UserAuthSession。 AuthProviders可以进一步自定义这些集合，AspNetWindowsAuthProvider可以添加Authenticated WindowsAuth Roles。

如上所示，角色/权限可以由实现IManageRoles API的AuthProviders管理，这是OrmLiteAuthProvider用来查看distinct RDBMS tables to validate Roles/Permissions的内容。

AWS Support

AWS支持的身份验证的缺失部分是基于DynamoDB的UserAuthRepository。已创建ServiceStack.AmazonWebServices占位符存储库以存储必要的功能。填写缺少的AWS部分是our TODO list，但由于需求较低，目前它的优先级较低。

需要注意的一点是，ServiceStack身份验证仅包含角色/权限的功能和过滤器属性。任何其他功能（如用户声明）都需要使用添加到ServiceStack's customizable Request Pipeline的自定义逻辑来实现。

DynamoDB会话状态＆amp; ServiceStack 4.0.32中的身份验证

1 个答案:

自定义用户角色和权限

AWS Support