|
GleeAuth
讨论 GLEE 的认证(Authz)与授权(Authn)模型
Phase-Design 简介GLEE 中的 Auth 组件包含了身份认证(authentication/authn)和授权许可(authorization/authz)两个部分。前者用于确认当前用户是谁,后者用于在必要的时候判断该用户是否可以进行某种行为。 设想的用例TODO 角色模型GLEE 中角色(Role)分为组角色(GroupRole)和用户角色(UserRole)。一种角色可以属于若干个组角色。一种组角色可以包含若干其他角色。系统初始化时需要内建以下角色:
授权许可项列表GLEE 系统提供了一个授权许可项列表,列出了所有授权许可项(PermissionItem)。所谓授权许可项,可以理解为是用于描述某种权限的名称。 一般情况下,授权许可项可以被描述为一个动宾短语,例如“访问库存信息”,“填写发货单”等等。许多时候,应用程序可能会需要对该动宾短语的宾语进行一定的限定,这可以通过添加适当的定语来实现,例如“访问成品的库存信息”、“修改自己创建的发货单”等等。无论如何,GLEE 的 Auth 系统不能为某个授权许可项是否能够像其语义所述的那样工作,这是应用程序应该负责的事务。 既然授权许可项以列表的形式表现,各个授权许可项对于 GLEE 而言是独立的,因此 GLEE 并不知道不同的授权许可项之间的优先关系。换句话说,一个被禁止“访问所有帮助”的用户可能被允许“访问模块 Foo 的帮助”。是否允许该用户“访问模块 Foo 的帮助”取决于应用程序的判断。 特别的,GLEE 设置了如下特殊的授权许可项:
与角色和授权许可不同,授权许可项在基于 GLEE 的应用开发过程中就已经确定,在运行时授权许可项列表是只读的。而毫无疑问,角色和授权许可均可以在运行时动态的创建、修改和删除。 授权许可授权许可(Permission)在角色和授权许可条目之间建立起具有语义的关联。一条授权许可信息必须关联到一种角色和一项授权许可条目,并明确的设置为允许(allow)或者禁止(deny)。 当应用程序使用 Auth 组件进行授权许可的判断时,在语义上类似向系统询问,“某种角色”是否可以进行“某一个授权许可条目”所描述的行为。例如,“匿名用户”是否可以“访问库存信息”? 当系统中存在这样明确的授权许可信息时,解读起来相当直观,结论或者是允许(allow),或者是禁止(deny),系统无须进一步(实际上,系统还是会首先判断该角色是否被禁止访问系统)的判断即可得出结论。 如果某一种角色与某一个特定的授权许可项之间并不存在明确的授权许可设置,则它既不是允许,也不是禁止,而应该被理解为未设置(unset)。这时候,GLEE 将根据角色的所属关系判断该角色是否具有相应的授权许可。 当角色与授权许可项之间不存在明确的关联,GLEE 将所有直接包含该角色的父角色,并按照优先顺序寻找相应的授权许可信息,如果存在明确的授权许可设置,则返回该授权信息。如果不存在明确的设置,则再次按照优先顺序寻找这些父角色的上一层角色。直到找到明确的设置为止。 |