My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
GleeAuth  
讨论 GLEE 的认证(Authz)与授权(Authn)模型
Phase-Design
Updated May 26, 2009 by xue...@gmail.com

简介

GLEE 中的 Auth 组件包含了身份认证(authentication/authn)和授权许可(authorization/authz)两个部分。前者用于确认当前用户是谁,后者用于在必要的时候判断该用户是否可以进行某种行为。

设想的用例

TODO

角色模型

GLEE 中角色(Role)分为组角色(GroupRole)和用户角色(UserRole)。一种角色可以属于若干个组角色。一种组角色可以包含若干其他角色。系统初始化时需要内建以下角色:

  • Everybody(GroupRole) - 所有人,用于反映包括注册用户和匿名用户在内的所有角色。该角色通常只用于全局的默认授权策略。
  • Authenticated Users(GroupRole) - 注册用户,原则上,应用程序创建的角色都包含于该角色中。
  • Anonymous user(UserRole) - 用于表示匿名用户。

授权许可项列表

GLEE 系统提供了一个授权许可项列表,列出了所有授权许可项(PermissionItem)。所谓授权许可项,可以理解为是用于描述某种权限的名称。

一般情况下,授权许可项可以被描述为一个动宾短语,例如“访问库存信息”,“填写发货单”等等。许多时候,应用程序可能会需要对该动宾短语的宾语进行一定的限定,这可以通过添加适当的定语来实现,例如“访问成品的库存信息”、“修改自己创建的发货单”等等。无论如何,GLEE 的 Auth 系统不能为某个授权许可项是否能够像其语义所述的那样工作,这是应用程序应该负责的事务。

既然授权许可项以列表的形式表现,各个授权许可项对于 GLEE 而言是独立的,因此 GLEE 并不知道不同的授权许可项之间的优先关系。换句话说,一个被禁止“访问所有帮助”的用户可能被允许“访问模块 Foo 的帮助”。是否允许该用户“访问模块 Foo 的帮助”取决于应用程序的判断。

特别的,GLEE 设置了如下特殊的授权许可项:

  • 进行未定义的行为(Perform undefined action)
    • 通常,针对 Everybody 将该授权许可项的许可设置为禁止(deny)
    • 通常,对于系统管理员性质的角色将该许可设置为允许(allow)
    • 当 GLEE 对某一中角色进行授权许可判断时,如果缺少明确的设置,将会尝试是否有对于该授权许可项的明确授权设置。如果被设置为允许(allow),则返回允许(allow)。
    • 由于授权许可判断有可能回溯到 Everybody 角色,因此对于 Everybody 将该授权许可项的许可设置为禁止(deny)意味着如果完全找不到明确的设置,就意味着禁止。

与角色和授权许可不同,授权许可项在基于 GLEE 的应用开发过程中就已经确定,在运行时授权许可项列表是只读的。而毫无疑问,角色和授权许可均可以在运行时动态的创建、修改和删除。

授权许可

授权许可(Permission)在角色和授权许可条目之间建立起具有语义的关联。一条授权许可信息必须关联到一种角色和一项授权许可条目,并明确的设置为允许(allow)或者禁止(deny)。

当应用程序使用 Auth 组件进行授权许可的判断时,在语义上类似向系统询问,“某种角色”是否可以进行“某一个授权许可条目”所描述的行为。例如,“匿名用户”是否可以“访问库存信息”?

当系统中存在这样明确的授权许可信息时,解读起来相当直观,结论或者是允许(allow),或者是禁止(deny),系统无须进一步(实际上,系统还是会首先判断该角色是否被禁止访问系统)的判断即可得出结论。

如果某一种角色与某一个特定的授权许可项之间并不存在明确的授权许可设置,则它既不是允许,也不是禁止,而应该被理解为未设置(unset)。这时候,GLEE 将根据角色的所属关系判断该角色是否具有相应的授权许可。

当角色与授权许可项之间不存在明确的关联,GLEE 将所有直接包含该角色的父角色,并按照优先顺序寻找相应的授权许可信息,如果存在明确的授权许可设置,则返回该授权信息。如果不存在明确的设置,则再次按照优先顺序寻找这些父角色的上一层角色。直到找到明确的设置为止。

Powered by Google Project Hosting