JS2 Security
1.
?
安全架構
1.1.?????
概述
Jetspeed 2 security leverages J2EE authentication and authorization standards for both authentication and authorization through the implementation of a default LoginModule and a default authorization Policy.
Authentication establishes the identity of the user and populates the Subject with all the user principals. In a portal context, the populated Subject is added to the session in the org.apache.jetspeed.security.SecurityValve implementation. The Subject principals are then used to authorize the user's access to a given resource. It leverages JAAS authorization by checking the user's permission with the AccessController. More details on authorization are provided in the JAAS authorization section of this documentation.
1.2.?????
圖示
The following diagram describes the high level security architecture:
2.
?
主要配置
Jetspeed 2 default security services configuration leverages a relational database as its default persitent datastore for security information. Jetspeed 2 security service provider interface provides a mechanism to replace the default datastore configured.
3 files are involved when configuring Jetspeed 2 security SPI. All the SPI configuration files are located under ${jetspeed-source-home}/portal/src/webapp/WEB-INF/assembly/ .
2.1.?????
security-atn.xml
This configuration file provides the login module configuration. Not everyone needs this, as some application may decide to use another login module other than the one provided.
2.2.?????
security-atz.xml
This configuration file configures the authorization policy, in J2's case RdbmsPolicy .
2.3.?????
security-managers.xml
This configuration file configures all the managers for security purpose.
2.4.?????
security-providers.xml
This configuration file configures the various providers and weaves the SPI together.
·
AuthenticationProviderProxy
: Configures the list of
AuthenticationProvider
and the default authenticator.
·???????????????????
????????????????????????????
·???????????????????
<bean id="org.apache.jetspeed.security.AuthenticationProviderProxy"
·???????????????????
???class="org.apache.jetspeed.security.impl.AuthenticationProviderProxyImpl"> ????? ???
·???????????????????
???<constructor-arg >
·???????????????????
??????<list>
·???????????????????
?????????<ref bean="org.apache.jetspeed.security.AuthenticationProvider"/>
·???????????????????
??????</list>
·???????????????????
???</constructor-arg>
·???????????????????
??<constructor-arg><value>DefaultAuthenticator</value></constructor-arg>
·???????????????????
</bean>
??????????????????????
?
·
AuthenticationProvider
: Configures the authentication providers for the current portal implementation. The example below configures the default authenticator that uses the RDBMS to manage/store user information.
·???????????????????
????????????????????????????
·???????????????????
<bean id="org.apache.jetspeed.security.AuthenticationProvider"
·???????????????????
??
???????????
???class="org.apache.jetspeed.security.impl.AuthenticationProviderImpl">? ????????????? ???
·???????????????????
???<constructor-arg index="0"><value>DefaultAuthenticator</value></constructor-arg>
·???????????????????
???<constructor-arg index="1"><value>The default authenticator</value></constructor-arg>
·???????????????????
???<constructor-arg index="2"><value>login.conf</value></constructor-arg>
·???????????????????
???<constructor-arg index="3">
·???????????????????
??????<ref bean="org.apache.jetspeed.security.spi.CredentialHandler"/>
·???????????????????
???</constructor-arg>
·???????????????????
???<constructor-arg index="4">
·???????????????????
??????<ref bean="org.apache.jetspeed.security.spi.UserSecurityHandler"/>
·???????????????????
???</constructor-arg>
·???????????????????
</bean>
???????????????????????
·
AuthorizationProvider
: Configures the policies and instantiates the
SecurityPolicies
that are used for enforcing permissions. By default, Jetspeed 2 does not load any other security policies that may have been configured. In order to use default policies, set
useDefaultPolicy
to
true
·???????????????????
????????????????????????????
·???????????????????
<bean id="org.apache.jetspeed.security.AuthorizationProvider"
·???????????????????
??
???????????
??class="org.apache.jetspeed.security.impl.AuthorizationProviderImpl">? ? ???
·???????????????????
????<constructor-arg index="0">
·???????????????????
????????<ref bean="org.apache.jetspeed.security.impl.RdbmsPolicy"/>
·???????????????????
????</constructor-arg>
·???????????????????
????<!-- Does not use the default policy as a default behavior -->
·???????????????????
????<constructor-arg index="1"><value>false</value></constructor-arg>??
·???????????????????
</bean>
???????????????????????
2.5.?????
security-spi.xml
This configuration file contains configuration that are common to the authentication and authorization SPIs.
|
Bean
|
Description
|
|
org.apache.jetspeed.security.spi.SecurityAccess
|
Used internally by the default OJB based SPI. Provide access to common action/methods for the various SPI implementations. The SecurityAccess bean is used by both the Authentication and Authorization SPIs.
|
2.6.?????
security-spi-atn.xml
This configuration file contains all the configurations for configuring the authentication SPI.
|
Bean
|
Description
|
|
org.apache.jetspeed.security.spi.CredentialHandler
|
The CredentialHandler encapsulates the operations involving manipulation of credentials. The default implementation provides support for password protection as defined by the PasswordCredentialProvider ; as well as lifecycle management of credentials through InternalPasswordCredentialInterceptor which can be configured to manages parameters such as maximum number of authentication failures, maximum life span of a credential in days and how much history to retain for a given credential.
|
|
org.apache.jetspeed.security.spi.UserSecurityHandler
|
The UserSecurityHandler encapuslated all the operations around the user principals.
|
The following simple
CredentialHandler
configuration is currently provided by default with Jetspeed:
<!-- require a non-empty password -->
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordValidator"
???? class="org.apache.jetspeed.security.spi.impl.DefaultCredentialPasswordValidator"/>
?
<!-- MessageDigest encode passwords using SHA-1 -->
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"
???? class="org.apache.jetspeed.security.spi.impl.MessageDigestCredentialPasswordEncoder">
???? <constructor-arg index="0"><value>SHA-1</value></constructor-arg>??????
</bean>??????
?
<!-- allow multiple InternalPasswordCredentialInterceptors to be used for DefaultCredentialHandler -->
<bean id="org.apache.jetspeed.security.spi.InternalPasswordCredentialInterceptor"
???? class="org.apache.jetspeed.security.spi.impl.InternalPasswordCredentialInterceptorsProxy">
???? <constructor-arg index="0">
?????? <list>
???????
?<!-- enforce an invalid preset password value in the persisent store is required to be changed -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.ValidatePasswordOnLoadInterceptor"/>
?
???????? <!-- ensure preset cleartext passwords in the persistent store? will be encoded on first use -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.EncodePasswordOnFirstLoadInterceptor"/>
?????? </list>
???? </constructor-arg>
</bean>
?
<bean id="org.apache.jetspeed.security.spi.PasswordCredentialProvider"
???? class="org.apache.jetspeed.security.spi.impl.DefaultPasswordCredentialProvider">
???? <constructor-arg index="0">
?????? <ref bean="org.apache.jetspeed.security.spi.CredentialPasswordValidator"/>
???? </constructor-arg>??????
???? <constructor-arg index="1">
?????? <ref bean="org.apache.jetspeed.security.spi.CredentialPasswordEncoder"/>
???? </constructor-arg>??????
</bean>??????
?
<bean id="org.apache.jetspeed.security.spi.CredentialHandler"
???? class="org.apache.jetspeed.security.spi.impl.DefaultCredentialHandler">??????
???? <constructor-arg index="0">
?????? <ref bean="org.apache.jetspeed.security.spi.SecurityAccess"/>
???? </constructor-arg>??????
???? <constructor-arg index="1">
?????? <ref bean="org.apache.jetspeed.security.spi.PasswordCredentialProvider"/>
???? </constructor-arg>??????
???? <constructor-arg index="2">
?????? <ref bean="org.apache.jetspeed.security.spi.InternalPasswordCredentialInterceptor"/>
???? </constructor-arg>
</bean>
?????????????????
The above configuration requires not much more than that a password should not be empty and MessageDigest encode it using SHA-1.
Before the 2.0-M4 release, Jetspeed came configured with a much stricter configuration, but for first time users of the Portal this was a bit overwelming and also quite difficult to configure differently.
With the 2.0-M4 release, the previously provided, and rather complex,
InternalPasswordCredentialInterceptor
implementations are split up in single atomic interceptors which can much easier be configured indepedently.
An overview of the new interceptors and how related request processing pipeline valves can be configured to provide feedback to the user is provided in the Credentials Management document.
Since the "old" (pre 2.0-M4) interceptors are no longer provided with Jetspeed, the example below shows how to "restore" the old setup using the new interceptors:
<!-- require a password of minimum length 6 and at least two numeric characters -->
<bean id="org.apache.jetspeed.security.spi.CredentialPasswordValidator"
???? class="org.apache.jetspeed.security.spi.impl.SimpleCredentialPasswordValidator">
???? <constructor-arg index="0"><value>6</value></constructor-arg>??????
???? <constructor-arg index="1"><value>2</value></constructor-arg>??????
</bean>
?
<!-- allow multiple InternalPasswordCredentialInterceptors to be used for DefaultCredentialHandler -->
<bean id="org.apache.jetspeed.security.spi.InternalPasswordCredentialInterceptor"
???? class="org.apache.jetspeed.security.spi.impl.InternalPasswordCredentialInterceptorsProxy">
???? <constructor-arg index="0">
?????? <list>
???????? <!-- enforce an invalid preset password value in the persisent store is required to be changed -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.ValidatePasswordOnLoadInterceptor"/>
?
???????? <!-- ensure preset cleartext passwords in the persistent store? will be encoded on first use -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.EncodePasswordOnFirstLoadInterceptor"/>
?
???????? <!-- remember the last 3 passwords used and require a new password to be different from those -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.PasswordHistoryInterceptor">
?????????? <constructor-arg index="0"><value>3</value></constructor-arg>??????
???????? </bean>
?
???????? <!-- Automatically expire a password after 60 days -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.PasswordExpirationInterceptor">
?????????? <constructor-arg index="0"><value>60</value></constructor-arg>??????
???????? </bean>
?
???????? <!-- Automatically disable a password after 3 invalid authentication attempts in a row -->
???????? <bean class="org.apache.jetspeed.security.spi.impl.MaxPasswordAuthenticationFailuresInterceptor">
?????????? <constructor-arg index="0"><value>3</value></constructor-arg>??????
???????? </bean>
?????? </list>
???? </constructor-arg>
</bean>
?????????????????
And, make sure something like the following configuration is set for the security related valves in pipelines.xml:
<bean id="passwordCredentialValve"
????? class="org.apache.jetspeed.security.impl.PasswordCredentialValveImpl"
????? init-method="initialize">
?<constructor-arg>
?? <!-- expirationWarningDays -->
?? <list>
???? <value>2</value>
???? <value>3</value>
???? <value>7</value>
?? </list>
?</constructor-arg>
</bean>
?
<bean id="loginValidationValve"
????? class="org.apache.jetspeed.security.impl.LoginValidationValveImpl"
???
??init-method="initialize">
? <!-- maxNumberOfAuthenticationFailures
?????? This value should be in sync with the value for
?????? org.apache.jetspeed.security.spi.impl.MaxPasswordAuthenticationFailuresInterceptor
?????? (if used) to make sense.
?????? Any value < 2 will suppress the LoginConststants.ERROR_FINAL_LOGIN_ATTEMPT
?????? error code when only one last attempt is possible before the credential
?????? will be disabled after the next authentication failure.
? -->
? <constructor-arg index="0"><value>3</value></constructor-arg>?
</bean>
?????????????????
Also, make sure the above valves are configured in the
jetspeed-pipeline
bean.
See the User Interaction section in the Credentials Management document for a description of these valves and their relation to the interceptors configuration.
2.7.?????
security-spi-atz.xml
This configuration file contains all the configurations for configuring the authorization SPI.
|
Bean
|
Description
|
|
org.apache.jetspeed.security.spi.RoleSecurityHandler
|
The RoleSecurityHandler encapsulates all the operations around the role principals.
|
|
org.apache.jetspeed.security.spi.GroupSecurityHandler
|
The GroupSecurityHandler encapsulates all the operations around the group principals.
|
|
org.apache.jetspeed.security.spi.SecurityMappingHandler
|
The SecurityMappingHandler encapsulates all the operations involving mapping between principals. It contains the logic managing hierarchy resolution for hierarchical principals (roles or groups). The default hierarchy resolution provided is a hierarchy by generalization (see overview for definitions). A contructor-arg can be added to the SecurityMappingHandler to change the hierarchy resolution strategy. Jetspeed 2 also support a hierarchy resolution by aggregation.
|
A sample
SecurityMappingHandler
configuration could be:
<!-- Security SPI: SecurityMappingHandler -->
<bean id="org.apache.jetspeed.security.spi.SecurityMappingHandler"
?
????class="org.apache.jetspeed.security.spi.impl.DefaultSecurityMappingHandler">? ???? ???
?? <constructor-arg >
????? <ref bean="org.apache.jetspeed.security.spi.SecurityAccess"/>
?? </constructor-arg>
?? <!-- Default role hierarchy strategy is by generalization.?
??????? Add contructor-arg to change the strategy. -->
?? <!-- Default group hierarchy strategy is by generalization.?
??????? Add contructor-arg to change the strategy. -->
</bean>
???????????????????
2.8.?????
結論和分析
|
配置文件
|
說明
|
分析
|
|
security-atn.xml
|
login module
配置文件
具體可參考：
|
提供了一個接口，可以實現不同的登陸模塊，實現不同的登陸認證過程
此時在
jetspeed2-security-{version}.jar
中包含配置文件
login.conf
，其內容為：
Jetspeed {
org.apache.jetspeed.security.impl.DefaultLoginModule equired;
};
In order to override this configuration, you can place your own login.conf file in your web application class path under WEB-INF/classes. The location of the login.conf file is configured in the security-providers.xml as described below.
|
|
security-atz.xml
|
authorization policy
配置文件
|
JAAS
認證策略的配置
|
|
security-managers.xml
|
UserManager
、
GroupManager
、
RoleManager
、
PermissionManager
配置文件
|
配置四個對象的關系管理實現
|
|
security-providers.xml
|
AuthenticationProvider
、
AuthenticationProviderProxy
、
SecurityProvider
、
AuthorizationProvider
授權認證提供者配置文件
|
?
|
說明：
1、?
關于
login module
可參考：
http://portals.apache.org/jetspeed-2/multiproject/jetspeed-security/login-module.html
?
3.
?
分析
3.1.?????
登陸認證過程分析
3.1.1.
????????
相關配置
主要參考
security-*.xml
等幾個安全相關的配置文件，尤其關注
security-providers.xml
，里面存在如下設置：
|
<!-- Security: Default Authentication Provider -->
? <bean id="org.apache.jetspeed.security.AuthenticationProvider"
?
???
???class="org.apache.jetspeed.security.impl.AuthenticationProviderImpl"
? >? ???? ???
?
???
???<constructor-arg index="0"><value>DefaultAuthenticator</value></constructor-arg>
?
???
???<constructor-arg index="1"><value>The default authenticator</value></constructor-arg>
?
???
???<constructor-arg index="2"><value>login.conf</value></constructor-arg>
?
???
???<constructor-arg index="3"><ref bean="org.apache.jetspeed.security.spi.CredentialHandler"/></constructor-arg>
?
???
???<constructor-arg index="4"><ref bean="org.apache.jetspeed.security.spi.UserSecurityHandler"/></constructor-arg>
? </bean>
|
這里設置了提供的默認認證方式，此時：
DefaultAuthenticator
——第一個參數是認證方式的名稱，意義不大；
The default authenticator
——第二個參數是認證方式的描述，意義不大；
login.conf
——第三個參數是認證配置文件的路徑，非常關鍵，這個文件可以在
jetspeed-security-2.0.jar
中找到，此時的配置為：
|
Jetspeed {
?? org.apache.jetspeed.security.impl.DefaultLoginModule required;
};
|
表示配置了一個
realm
，名稱為
Jetspeed
，實現類為
org.apache.jetspeed.security.impl.DefaultLoginModule
。此時回顧
web.xml
中的如下描述：
|
<!-- Login configuration uses form-based authentication -->
? <login-config>
??? <auth-method>FORM</auth-method>
??? <realm-name>Jetspeed</realm-name>
??? <form-login-config>
????? <form-login-page>/login/login</form-login-page>
????? <form-error-page>/login/error</form-error-page>
??? </form-login-config>
? </login-config>
|
此時使用的
realm
就是
Jetspeed
，關聯起來了吧。
第三、第四個參數是回調
3.1.2.
????????
調用過程
1、?
（
*
）
LoginServlet.java(doGet)
：觸發登陸的
submit
；
2、?
進入
servlet container
中觸發
FormAuthenticator.authenticate
認證（請看配置設置：
<auth-method>FORM</auth-method>
）；
3、?
（
*
）
org.apache.jetspeed.security.impl.DefaultLoginModule.java
：根據
web.xml
配置的
realm-name
（
Jetspeed
）確定認證模塊（
login module
），并調用
login()
方法，在該方法中調用順序如下：
a)????????
設置回調；
b)???????
調用
org.apache.jetspeed.security.impl.UserManagerImp
.java
的
authenticate(this.username, password)
進行認證，繼續跟進該方法：
?????????????????????????????????????? i.?????????????
除非當前用戶是匿名用戶，否則調用
org.apache.jetspeed.security.impl.AuthenticationProviderProxyImpl
.java
的
authenticate(userName, password, providerName)
方法進行認證，此時該
provider
會調用其
CredentialHandler
（感覺就是
DAO,
此為
org.apache.jetspeed.security.spi.impl.DefaultCredentialHandler
.java
）的
authenticate(userName, password)
進行真正的驗證。
3.2.?????
數據結構分析
從數據庫模型來分析：
1、?
SECURITY_PRINCIPAL
：包含了用戶、角色、組的信息，都認為是
PRINCIPAL
（主體）；
2、?
SECURITY_CREDENTIAL
：用戶的證書，默認為密碼，這樣設計表明一個
PRINCIPAL
可以有多個
CREDENTIAL
；
3、?
SECURITY_PERMISSION
：基于
JAAS
的權限的定義，目前分為
FOLDER
、
PAGE
、
PORTLET
等類型（可以擴展嗎？）
3.3.?????
與傳統機構部門、人員、角色、組設計的分析
從目前設計來看，存在如下問題：
1、?????????????
GROUP
直接放在
SECURITY_PRINCIPAL
，也是一個
PRINCIPAL
，與用戶、角色類似進行處理，顯然不符合實際需要；
2、?????????????
這里的用戶、角色關注的是“權限”的概念，并無業務概念，顯然也存在一定的需求障礙（根據
JSR168
用戶信息可以很方便的擴展，這個需要再深入了解
）
4.
?
初步方案
4.1.?????
改良方案
通過修訂
/
擴展上述
PDM
的幾個表，并通過調整相關
ojb
的幾個
XML
配置文件
(
請參考
src_security\JETSPEED-INF\ojb\security_repository.xml)
，可以較為輕松的完成擴展。
但我個人并不傾向這么做，原因是：
1、?
我們不熟悉
OJB
；
2、?
我們并不打算在
j2-admin
中完善該管理過程——工作量不小，意義卻不大；
3、?
我們已經有比較好的機構用戶管理模塊，比如
Ioa5
中的實現。
4.2.?????
改革方案：與
UUM
的結合
從理論上說，這是可行的：
1、?????????????
可以通過實現
GroupManager
、
UserManager
、
RoleManager
接口，替換
/
擴展現有的幾個默認實現（
org.apache.jetspeed.security.impl.*ManagerImpl
），達到控制幾個對象的管理；
2、?????????????
可以通過替換
/
擴展現有的幾個默認
SPI
實現（具體請參考
org.apache.jetspeed.security.spi
下的
CredentialHandler
、
UserSecurityHandler
、
RoleSecurityHandler
、
GroupSecurityHandler
等），達到
DAO
的效果，操作包括
RDBMS/LDAP
的數據訪問和存取
5.
?
附件
5.1.?????
Login Module Implementation
The
DefaultLoginModule
implementation is illustrated by the class diagram below:
The roles of the classes used to implement the DefaultLoginModule are:
|
Class
|
Description
|
|
org.apache.jetspeed.security.impl.DefaultLoginModule
|
The
javax.security.auth.spi.LoginModule
implementation. The
DefaultLoginModule
authentication decision is encapsulated behind the
UserManager
interface which leverages the SPI implementation to decide which authenticator should be used in order to authenticate a user against a specific system of record. For more information on how to implement your own authenticator, see the authentication SPI documentation.
|
|
org.apache.jetspeed.security.LoginModuleProxy
|
A utility component used to expose the
UserManager
to the
DefaultLoginModule
.
|
|
org.apache.jetspeed.security.User
|
The
User
is an interface that holds the
javax.security.auth.Subject
and his/her
java.util.prefs.Preferences
. The
UserManager
upon user authentication populates the user subject with all user
java.security.Principal
. Jetspeed 2 implements 3 types of principals:
·??
UserPrincipal: The principal holding the user unique identifier for the application.
·??
RolePrincipal: The principal representing a role for the system.
·??
GroupPrincipal: The principal representing a group for the system.
|
|
org.apache.jetspeed.security.UserManager
|
The interface exposing all user operations. This interfaces fronts the aggregates various SPI to provide developers with the ability to map users to their specific system of record.
|
?