我正在设计一个RESTful Web应用程序，它将为其他几个应用程序提供身份验证系统。其他应用程序将通过HTTP查询此应用程序并获取描述经过身份验证的用户的XML。
身份验证应用需要跟踪允许哪些用户 对执行什么。
我正在研究数据库架构。以下是我的初步设计。 （假设每个表都有一个id列。）
applications # The various client apps that will query this auth system.
------------
name
users # Table simplified for discussion
-----
username
password
email
roles
-----
name
application_id
roles_users
-----------
role_id
user_id
这个想法是说某人试图在“装备库存”应用程序中执行管理功能。所以“设备库存”会告诉auth系统“用户名xxx和密码yyy获取用户”。然后它将查看返回的（通过ActiveResource）User对象并检查其roles数组是否包含名称为“ADMIN”的Role，其本身属于{{1}名称为“设备清单”的对象。
或许最好删除Application表并拥有更多角色，例如“applications”，“equipment_inventory_admin”，“equipment_inventory_readonly”，等
更重要的是，规范化Application实体还是简化表结构？也许在打字之后我刚刚回答了我自己的问题，但是欢迎提出意见或建议。
答案 0 :(得分：1)
架构看起来很健全， 你会发送
<login><username>abc</username><password>xyz</password><app>51</app></login>
然后你回来了
<auth>
<user>
<username>abc</a>
<lastlogin>123456464</lastlogin>
</user>
<app>
<name>Equipment Inventory</name>
<version>3.1.5e</version>
</app>
<roles>
<role>admin</role>
<role>manager</role>
<role>dataentry</role>
</roles>
</auth>
或
<auth><error type="1"></auth>
答案 1 :(得分：1)
绝对单独的身份验证与授权。 （看起来你正在这样做;“用户”表属于身份验证，其余的+ user.id属于授权）
密码：你不是把它们存放在明文中，不是吗？存储MD5哈希值（+ salt以防止攻击）会更安全。
Kerberos会有可能吗？ （也许它可以适应通过HTTP作为传输层工作）
答案 2 :(得分：0)
就我个人而言，我倾向于在规范化方面犯错误。至少根据我的经验，可以添加一些额外的模块。在必要时在应用程序和全新表中添加额外的行更容易，然后编辑现有的架构并更新所有相关的数据访问代码。
编辑：再看看你可以合并角色表和roles_users表。它可以是一个定义角色以及用户如何为每个应用程序访问它们的地方。