Junky's IT Notebook

Liferay 安全管理(转)

企业应用整合成为了越来越多的企、事业单位的当务之急，我所处环境也不可避免的遇到这个棘手的问题，各种技术的交集使得portal技术有了大显身手之处。可惜IBM、BEA的高额费用让我们望而却步，自然，开源的portal成为了首选，Liferay是开源社区里一个非常活跃的项目：）而且重要的是其技术架构如图1，也和我们现在的技术路线相近，所以我们决定采用Liferay（版本：liferay-portal-src-4.1.2）作为基础来进行应用开发和系统整合。

图1 Liferay技术架构

  

要用好这个基础平台，必须要对她的自身实现原理有个比较清晰的认识，以下文章为我在研究Liferay原理时所做的一些笔记，现整理和分享（由于笔记带有强烈的个人思想，有错误再所难免，希望能对进一步的分析做为铺垫，更欢迎批评指正）。

 

Liferay Portal

Liferay 的JAAS权限管理

Liferay的业务逻辑管理

Liferay二次开发

Liferay WSRP

 

Liferay的权限管理实现了一个典型的JAAS管理策略，所以在分析其本身前，在此首先介绍JAAS的验证原理和Tomcat上如何开发标准JAAS应用。

 JAAS验证原理

JAAS的核心类和接口可以被分为三种类型，大多数都在javax.security.auth包中。在J2SE 1.4中，还有一些接口的实现类在com.sun.security.auth包中，如下所示：

& #61557;       普通类 Subject，Principal，Credential(凭证)

　Subject类代表了一个验证实体，它可以是用户、管理员、Web服务，设备或者其他的过程。该类包含了三中类型的安全信息：

1)        身份（Identities）：由一个或多个Principal对象表示

2)        公共凭证（Public credentials）：例如名称或公共密钥

3)        私有凭证（Private credentials）：例如口令或私有密钥

　　Principal对象代表了Subject对象的身份。它们实现了java.security.Principal和java.io.Serializable接口。在Principal类中，最重要的方法是getName（）。该方法返回一个身份名称。在Subject对象中包含了多个Principal对象，因此它可以拥有多个名称。由于登录名称、身份证号和Email地址都可以作为用户的身份标识，可见拥有多个身份名称的情况在实际应用中是非常普遍的情况。

在上面提到的凭证并不是一个特定的类或借口，它可以是任何对象。凭证中可以包含任何特定安全系统需要的验证信息，例如标签（ticket），密钥或口令。Subject对象中维护着一组特定的私有和公有的凭证，这些凭证可以通过Subject 方法getPrivateCredentials（）和getPublicCredentials（）获得。这些方法通常在应用程序层中的安全子系统被调用。

& #61557;       验证 LoginContext，LoginModule，CallBackHandler，Callback

验证：LoginContext

　　在应用程序层中，你可以使用LoginContext对象来验证Subject对象。LoginContext对象同时体现了JAAS的动态可插入性（Dynamic Pluggability），因为当你创建一个LoginContext的实例时，你需要指定一个配置。LoginContext通常从一个文本文件中加载配置信息，这些配置信息告诉LoginContext对象在登录时使用哪一个LoginModule对象。

　　下面列出了在LoginContext中经常使用的三个方法：

& #61550;         login () 进行登录操作。该方法激活了配置中制定的所有LoginModule对 象。如果成功，它将创建一个经过了验证的Subject对象；否则抛出LoginException异常。

& #61550;         getSubject () 返回经过验证的Subject对象

& #61550;         logout () 注销Subject对象，删除与之相关的Principal对象和凭证

　　验证：LoginModule

　　LoginModule是调用特定验证机制的接口。J2EE 1.4中包含了下面几种LoginModule的实现类：

& #61550;         JndiLoginModule 用于验证在JNDI中配置的目录服务

& #61550;         Krb5LoginModule 使用Kerberos协议进行验证

& #61550;         NTLoginModul 使用当前用户在NT中的用户信息进行验证

& #61550;         UnixLoginModule 使用当前用户在Unix中的用户信息进行验证

 

　　同上面这些模块绑定在一起的还有对应的Principal接口的实现类，例如NTDomainPrincipal和UnixPrincipal。这些类在com.sun.security.auth包中。

 

　　LoginModule接口中包含了五个方法：

1)        initialize () 当创建一LoginModule实例时会被构造函数调用

2)        login () 进行验证,通常会按照登录条件生成若干个Principal对象

3)        commit () 进行Principal对象检验，按照预定义Principal条件检验Login生成的Principal对象，所有需要的条件均符合后，把若干个生成的Principal对象付给Subject对象，JAAS架构负责回传给LoginContext.

4)        abort () 当任何一个LoginModule对象验证失败时都会调用该方法。任何已经和Subject对象绑定的Principal对象都会被解除绑定。

5)        logout () 删除与Subject对象关联的Principal对象和凭证，消除Subject,Principal等认证对象。

　验证：CallbackHandler和Callback

　　CallbackHandler和Callback对象可以使LoginModule对象从系统和用户那里收集必要的验证信息，同时独立于实际的收集信息时发生的交互过程。

　　

　　JAAS在javax.sevurity.auth.callback包中包含了七个Callback的实现类和两个CallbackHandler的实现类：ChoiceCallback、ConfirmationCallback、LogcaleCallback、NameCallback、PasswordCallback、TextInputCallback、TextOutputCallback、DialogCallbackHandler和TextCallBackHandler。Callback接口只会在客户端会被使用到。我将在后面介绍如何编写你自己的CallbackHandler类。

 

授权 Policy，AuthPermission，PrivateCredentialPermission

要了解Liferay（tomcat版本）的权限管理，必须首先了解JAAS在tomcat上的应用。

 

u          Tomcat服务器JAAS配置方法

　　和在应用程序运行JAAS不同的是，配置JAAS方法会有很不一样。我们使用的是Tomcat 5.0.x 应用服务器，它的JAAS配置方法有数种，分别是

& #61557;       JAASRealm

& #61557;       JDBCRealm

& #61557;       DataSourceRealm

& #61557;       JNDIRealm

& #61557;       MemoryRealm

JAASRealm

 

1.         把自定义 LoginModule、User、Role等相关类放入Tomcat 的 classpath

2.         把自定义login.config JAAS配置文件配置进JVM环境，例如： JAVA_OPTS=-DJAVA_OPTS=-Djava.security.auth.login.config==$CATALINA_HOME/conf/jaas.config

3.         设置 web.xml里的 security-constraints 标签设定需要保护的资源

4.         在$CATALINA_HOME/conf/server.xml里engine标签里设置JAASRealm标签

以下是JAASRealm标签的详细说明

 

以下是完整的tomcat服务器配置例子：

在%TOMCAT_HOME%/config/server.xml 中添加以下段落

<Realm className="org.apache.catalina.realm.JAASRealm"            

                appName="MyFooRealm"      

    userClassNames="org.foobar.realm.FooUser"      

     roleClassNames="org.foobar.realm.FooRole"

                      debug="99"/>

上面介绍了tomcat的应用，而liferay（tomcat版本）也是利用了这种标准的tomcat的JAAS实现。

与权限管理、用户认证的主要类包为：

com.liferay.portal.security.auth.*

com.liferay.portal.service.permission

com.liferay.portal.struts.PortalRequestProcessor

 

Liferay关于JAAS的实现包都在com.liferay.portal.security.auth.*下，在$catalina_home/conf/jaas.conf中定义了Liferay实现的loginModule，在我使用的版本中，PortalLoginModule将首先通过对象池取出一个自定义Liferay用户自定义的实现，即也可以在portal中再次自定义loginModule。显然，如果没有自定义的实现，将根据用户所使用的服务器自动进行选择默认实现。

Liferay自身所实现的user Principals和role Principals也仅仅是保存了用户的userid，以其作为自身标识，在登陆成功时赋予了所有用户“users”角色：

PortalRole role = new PortalRole("users");

getSubject().getPrincipals().add(role);

Liferay的PortalRequestProcessor扩展了TilesRequestProcessor，实现了自定义的请求处理流程。在请求流程中复写了processRoles（），在这个函数中进行了用户权限的判断，从而达到了对web资源的保护。

Permission是Liferay定义的用户访问的权限判断，由processRoles调用进行访问控制。

值得一提的是，Liferay本身也含有登陆模块，这个登陆模块所做的主要工作为通过认证确定用户的登陆信息正确，并通过用户的登陆信息取得用户userid存放在session中，为JAAS的登陆模块提供基础（即通过登陆的正确用户id与密码）。登陆的用户默认为LDAP登陆，但是为默认禁用，所以用户认证Liferay都通过一个数据库的认证实现在loginAction中进行的用户判断，取出了userid和password存放在session中。

整个过程如下：

 

如上图所示，触发JAAS的登陆模块的是在登陆成功后转向了/c/portal/protected，而此路径为tomcat的安全域，所以tomcat将调用用户自定义的登陆模块进行用户认证，通过认证后通过对用户角色的对比，来判断用户是否允许访问。

 图2 Liferay认证流程

  

 

副录：帮助进行相关类查看

SecureFilter->进行访问地址限制和是使用安全连接转换。

PropsUtil—〉portal-ejb.jar里的portal.property

MainServlet 扩展Struts的action Serverlet，进行映射。

posted on 2007-05-31 13:45 junky 阅读(1316) 评论(0)  编辑  收藏 所属分类: portal