架构平台的授权许可模式 [英] Architecting a platform authorization permission model

问题描述

在任何平台的一个重要组成部分（PaaS的）身份验证的安全性是能够限制和/或定义每认证一个特定的应用程序或用户的任何一个用户/应用基础或在权利或权限的基础。

An important part of any platform (PaaS) authentication's security is to be able to limit and/or define a particular application or user's "rights" or permissions on either a user/app basis or a per-authentication basis.

在现代化的平台或产品的API中发现的常见的权限模型是基于作用域的想法。在我的研究， GitHub的，的 Facebook的， Instagram的，<一个href=\"http://www.etsy.com/developers/documentation/getting_started/oauth#section_permission_scopes\">Etsy （及以上）都使用许可造型这种风格在他们的OAuth实现。然而，这个范围模式似乎只关注如何外部（即第三方）应用程序访问身份验证的用户的数据。

The common permission model found in modern platform or product API’s is based on an idea of "Scopes". In my research, GitHub, Facebook, Instagram, Etsy (and more) all use this style of permission modeling in their OAuth implementations. However, this "scopes" model seems to be only concerned with how external (ie. third party) applications access an authenticated user’s data.

在内部，权限模型似乎不是更侧重于一个角色基于模型（管理员，版主，用户等）或其他一些自定义实现的。

Internally, permission models seem to be either more focused on a "role" based model (admin, moderator, user, etc) or a number of other custom implementations.

我的问题是这样的：什么权限模型将最适合现代PaaS的，就是想从一定的措施都限制了它的用户和访问用户的数据限制了第三方应用程序，以及如何在被构建绩效意识地？

我最初的研究使我到一个基于范围的权限模型的内部和外部使用。不幸的是，架构这样的系统是不平凡的。我已经看到了创建这种架构的多种方法：

My initial research led me to an internal and external usage of a scope-based permission model. Unfortunately, architecting such a system isn’t trivial. I’ve seen multiple methods of creating such an architecture:

1. 的AR-友好关系数据库的方式：

1. The AR-friendly relational DB way:

• 创建具有连接表的权限，用户可用权限，用户的令牌，用户令牌的活动权限列表之间的许多一对多关系的多个表。

• Creating multiple tables with join tables for a many-to-many relationship between a list of permissions, a user’s available permissions, a user’s token, and a user token’s active permissions.

一个用户可以使用令牌身份验证，并指定尽可能多的权限，可在该令牌的最高最初设置该用户的权限

A user may authenticate with a token and specify as many permissions to be available on that token up to the permissions originally set for that user

聪明位屏蔽方式：

• 在数据集中使用一个简单的整数列来存储一个整数值

• Using a simple integer column in a data set to store an integer value

的整数值是二进制的方式访问，使用位运算符来设置，获取切换（等）的用户通过重新presenting许可作为单个位

The integer value is accessed in a binary way, using bitwise operators to set, get, toggle (etc) the permissions of a user or their token by representing a permission as a single bit

他们似乎有一些优点和缺点每个。该AR-友好的方式似乎是它的一个非常灵活的解决方案，而且看起来它可能是一个严重的性能命中，因为多个连接/查询都必须运行和ORM模型实例都必须在每个经过身份验证创建呼叫即可。的比特掩蔽方法似乎将是非常快速和有效的，但将是不太直观开发并会更容易出错。另外，位掩码看起来这将是一个限制的解决方案也只是轻易让一个很二权限模型（能或不能做的），没有中间路线/幸福的介质，它会限制权限基于硬件限制的硬64位的限制。

Their seems to be some pros and cons to each. The AR-friendly way seems like its a very flexible solution, but also seems like it could be a serious performance hit, since multiple joins/queries would have to be run and ORM model instances would have to be created on every authenticated call. The Bit-masking method seems like it would be very fast and efficient, but would be less intuitive to develop and would be more prone to error. Also, bit-masking seems like it would be a limiting solution in that it would only easily allow a very "binary" permission model (can or cannot do) with no middle-ground/happy-medium and that it would limit the permissions to a hard 64-bit limit based on hardware limitations.

是否有权限模型或架构，我很想念/没有想到的另一种方法？还是我在正确的轨道上，性能考虑是不是一个巨大的关注（尽可能的关系方法进入），因为我做出来的人？

感谢你了！

什么权限模型将最适合现代PaaS的，就是想从一定的措施都限制了它的用户和访问用户的数据限制了第三方应用程序，以及如何在性能自觉的方式来架构？

What permission model would best fit a modern PaaS that would like to both limit its users from certain actions AND limit 3rd party applications from accessing a user’s data, and how could that be architected in a performance conscious way?

推荐答案

我会看看Spring Security的ACL开始。它们使用位掩码，并且可以（相对）容易地与像ehcache的高速缓存集成。如果你使用JPA进行数据访问，您可以使用JPA的缓存了。

I would start with a look at Spring Security ACL. They use bit masks, and can be (relatively) easily integrated with a cache like ehcache. If you use JPA for data access, you can use JPA's cache too.

<一个href=\"http://static.springsource.org/spring-security/site/docs/current/reference/springsecurity.html\" rel=\"nofollow\">http://static.springsource.org/spring-security/site/docs/current/reference/springsecurity.html

的模式：

的http://static.springsource.org/spring-security/site/docs/3.0.x/reference/appendix-schema.html

OAuth的：

http://static.springsource.org/spring-security/oauth/

这篇关于架构平台的授权许可模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！