apache shiro_Apache Shiro第2部分–领域，数据库和PGP证书
apache shiro
這是致力于Apache Shiro的系列文章的第二部分。 我們從簡單的不安全Web應用程序開始了上一部分 。 完成后，該應用程序具有基本的身份驗證和授權。 用戶可以登錄和注銷。 所有網頁和按鈕均已分配并實施了訪問權限。 授權和身份驗證數據都已存儲在靜態配置文件中。正如我們在最后一部分中承諾的，我們將用戶帳戶數據移至數據庫。 另外，我們將為用戶提供通過PGP證書進行身份驗證的選項。 因此，我們的應用程序將具有多個備用登錄選項：使用用戶名/密碼登錄和使用證書登錄。 最后，我們將強制啟用備用登錄選項。
換句話說，我們將展示如何創建自定義領域以及如何處理多領域方案。 我們將創建三個不同版本的SimpleShiroSecuredApplication：
- 版本，并將所有帳戶信息移至數據庫 ，
- 允許PGP證書作為替代身份驗證機制的版本 ，
- 需要同時輸入用戶名/密碼和PGP證書的版本 。
每個版本都有測試類RunWaitTest。 該類使用在http：// localhost：9180 / simpleshirosecuredapplication / url上部署的應用程序啟動Web服務器。
注意：自第一版以來，我們更新了上一部分。 最顯著的變化是新部分 ，該部分顯示了如何向登錄頁面添加錯誤消息。 感謝大家的反饋。
境界
首先，我們解釋什么是領域以及如何創建它們。 如果您對理論不感興趣，請繼續下一章 。
領域負責身份驗證和授權。 每當用戶想要登錄到應用程序時，都會收集身份驗證信息并將其傳遞到領域。 Realm驗證提供的數據并決定是否應允許用戶登錄，訪問資源或擁有特定角色。
認證信息包括兩個部分：
- 主體–代表帳戶唯一標識符，例如用戶名，帳戶ID，PGP證書等。
- 憑證–證明用戶身份，例如密碼，PGP證書，指紋等。
Shiro提供了能夠從活動目錄 ， ldap ， ini文件 ， 屬性文件和數據庫中讀取授權數據的領域。 在Shiro.ini文件的主要部分中配置領域：
realmName=org.apache.shiro.realm.jdbc.JdbcRealm認證方式
所有領域都實現Realm接口。 有兩種重要的接口方法：supports和getAuthenticationInfo。 兩者都在身份驗證令牌對象中接收主體和憑據。
支持方法根據提供的身份驗證令牌確定領域是否能夠對用戶進行身份驗證。 例如，如果我的領域檢查用戶名和密碼，則僅使用X509證書拒絕身份驗證令牌。
方法getAuthenticationInfo本身執行身份驗證。 如果來自身份驗證令牌的主體和憑據表示有效的登錄信息，則該方法返回身份驗證信息對象。 否則，領域返回null。
授權書
如果該領域還希望進行授權，則必須實現Authorizer接口。 每個Authorizer方法都將主體作為參數，并檢查角色或權限。 重要的是要理解，該領域會獲得所有授權請求，即使它們來自另一個領域進行了身份驗證的用戶也是如此。 當然，領域可以決定忽略任何授權請求。
權限以字符串或權限對象的形式提供。 除非有充分的理由，否則請使用WildcardPermissionResolver將字符串轉換為權限對象。
其他選擇
Shiro框架在運行時調查其他接口的領域。 如果領域實現了它們，則可以使用：
- 有關用戶注銷的信息，
- 有關系統啟動的信息，
- 全局緩存
- 在配置文件中配置的名稱 ，
- 在權限字符串和權限對象之間配置的轉換器 。
這些功能可用于實現其他接口的任何領域。 無需其他配置。
自定義領域
創建新領域的最簡單方法是擴展AuthenticatingRealm或AuthorizingRealm類。 它們具有上一節中提到的所有有用接口的合理實現。 如果它們不能滿足您的需求，則可以擴展CachingRealm或從頭開始創建新領域。
移至數據庫
當前版本的SimpleShiroSecuredApplication使用默認領域進行身份驗證和授權。 默認領域– IniRealm從配置文件讀取用戶帳戶信息。 這種存儲僅對于最簡單的應用程序是可接受的。 任何稍微復雜的事情都需要將憑據存儲在更好的持久性存儲中。
新要求：帳戶憑據和訪問權限存儲在數據庫中。 存儲的密碼經過哈希處理和加鹽處理。
在本章中，我們將把應用程序連接到數據庫并創建表以存儲所有用戶帳戶數據。 然后，我們將IniRealm替換為能夠從數據庫和salt密碼讀取的領域。
數據庫基礎架構
本節介紹示例應用程序基礎結構。 它不包含有關Shiro的信息，因此您可以自由地跳過它 。
示例應用程序以嵌入式模式使用Apache Derby數據庫。
我們使用Liquibase進行數據庫部署和升級。 它是開源庫，用于跟蹤，管理和應用數據庫更改。 數據庫更改（新表，新列，外鍵）存儲在數據庫更改日志文件中。 啟動后，Liquibase會調查數據庫并應用所有新更改。 結果，數據庫始終保持一致并且是最新的，而我們卻沒有付出任何努力。 將對Derby和Liquibase的依賴項添加到SimpleShiroSecuredApplication pom.xml中 ：
將jndi添加到碼頭：
<dependency><groupid>org.mortbay.jetty</groupid><artifactid>jetty-naming</artifactid><version>${jetty.version}</version><scope>test</scope> </dependency> <dependency><groupid>org.mortbay.jetty</groupid><artifactid>jetty-plus</artifactid><version>${jetty.version}</version><scope>test</scope> </dependency>使用數據庫結構描述創建db.changelog.xml文件。 它創建用于存儲用戶，角色和權限的表。 它還用初始數據填充這些表。 我們使用random_salt_value_username作為鹽，并使用以下方法創建哈希鹽化密碼：
public static String simpleSaltedHash(String username, String password) {Sha256Hash sha256Hash = new Sha256Hash(password, (new SimpleByteSource('random_salt_value_' + username)).getBytes());String result = sha256Hash.toHex();System.out.println(username + ' simple salted hash: ' + result);return result; }在WEB-INF / jetty-web.xml文件中創建指向derby的數據源：
<configure class='org.mortbay.jetty.webapp.WebAppContext' id='SimpleShiroSecuredApplication'><new class='org.mortbay.jetty.plus.naming.Resource' id='SimpleShiroSecuredApplication'><arg>jdbc/SimpleShiroSecuredApplicationDB</arg><arg><new class='org.apache.derby.jdbc.EmbeddedDataSource'><set name='DatabaseName'>../SimpleShiroSecuredApplicationDatabase</set><set name='createDatabase'>create</set></new></arg></new> </configure>在web.xml文件中配置數據源和liquibase：
<resource-ref><description>Derby Connection</description><res-ref-name>jdbc/SimpleShiroSecuredApplicationDB</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth> </resource-ref><context-param><param-name>liquibase.changelog</param-name><param-value>src/main/resources/db.changelog.xml</param-value> </context-param><context-param><param-name>liquibase.datasource</param-name><param-value>jdbc/SimpleShiroSecuredApplicationDB</param-value> </context-param><listener><listener-class>liquibase.integration.servlet.LiquibaseServletListener</listener-class> </listener>最后，在啟用了jndi的情況下配置為讀取jetty-web.xml的jetty在AbstractContainerTest類中。
創建新領域
Shiro提供的JDBCRealm能夠執行身份驗證和授權。 它使用可配置SQL查詢從數據庫中讀取用戶名，密碼，權限和角色。 不幸的是，該領域有兩個缺點：
- 它無法從JNDI加載數據源（ 未解決的問題 ）。
- 它無法添加密碼（ 未解決的問題 ）。
我們對其進行擴展，并創建新的類JNDIAndSaltAwareJdbcRealm 。 由于所有屬性都可以在ini文件中進行配置，因此新屬性jndiDataSourceName也將自動進行配置。 只要設置了新屬性，該領域就會在JNDI中查找數據源：
protected String jndiDataSourceName;public String getJndiDataSourceName() {return jndiDataSourceName; }public void setJndiDataSourceName(String jndiDataSourceName) {this.jndiDataSourceName = jndiDataSourceName;this.dataSource = getDataSourceFromJNDI(jndiDataSourceName); }private DataSource getDataSourceFromJNDI(String jndiDataSourceName) {try {InitialContext ic = new InitialContext();return (DataSource) ic.lookup(jndiDataSourceName);} catch (NamingException e) {log.error('JNDI error while retrieving ' + jndiDataSourceName, e);throw new AuthorizationException(e);} } 方法doGetAuthenticationInfo從數據庫讀取帳戶身份驗證信息，并將其轉換為身份驗證信息對象。 如果找不到帳戶信息，則返回null。 父類AuthenticatingRealm將身份驗證信息對象與原始用戶提供的數據進行比較。
我們重寫doGetAuthenticationInfo以從數據庫中讀取密碼哈希和鹽，并將它們存儲在身份驗證信息對象中：
這里的示例僅包含最重要的代碼段。 在Github上有完整課程 。
配置新領域
在Shiro.ini文件中配置領域和jndi名稱：
[main] # realm to be used saltedJdbcRealm=org.meri.simpleshirosecuredapplication.realm.JNDIAndSaltAwareJdbcRealm # any object property is automatically configurable in Shiro.ini file saltedJdbcRealm.jndiDataSourceName=jdbc/SimpleShiroSecuredApplicationDB # the realm should handle also authorization saltedJdbcRealm.permissionsLookupEnabled=true配置SQL查詢：
# If not filled, subclasses of JdbcRealm assume 'select password from users where username = ?' # first result column is password, second result column is salt saltedJdbcRealm.authenticationQuery = select password, salt from sec_users where name = ? # If not filled, subclasses of JdbcRealm assume 'select role_name from user_roles where username = ?' saltedJdbcRealm.userRolesQuery = select role_name from sec_users_roles where user_name = ? # If not filled, subclasses of JdbcRealm assume 'select permission from roles_permissions where role_name = ?' saltedJdbcRealm.permissionsQuery = select permission from sec_roles_permissions where role_name = ?JdbcRealm使用credetials匹配器的方式與IniRealm完全相同：
# password hashing specification sha256Matcher = org.apache.shiro.authc.credential.HashedCredentialsMatcher sha256Matcher.hashAlgorithmName=SHA-256 saltedJdbcRealm.credentialsMatcher = $sha256Matcher注意：我們從配置文件中刪除了[用戶]和[角色]部分。 否則，Shiro將同時使用IniRealm和JdbcRealm。 這將創建超出本章范圍的多領域方案。
從用戶的角度來看，應用程序的工作方式與以前完全相同。 他可以登錄到以前相同的用戶帳戶。 但是，用戶名，密碼，鹽，權限和角色現在存儲在數據庫中。
完整的源代碼可在Github上的'authentication_stored_in_database'分支中找到。
備用登錄–證書
一些系統允許用戶登錄使用多種身份驗證方式。例如，用戶可以提供用戶名/密碼，使用Google帳戶，Facebook帳戶或其他任何方式登錄。 我們將添加與簡單應用程序類似的內容。 我們將為用戶提供使用PGP證書進行身份驗證的選項。
新要求：應用程序支持PGP證書作為替代身份驗證機制。 僅當用戶不擁有與應用程序帳戶關聯的有效證書時，才會顯示登錄屏幕。 如果用戶具有有效的已知PGP證書，則會自動登錄。
用戶嘗試登錄應用程序時，必須提供身份驗證數據。 這些數據由servlet過濾器捕獲。 過濾器將數據轉換為身份驗證令牌，并將令牌傳遞給領域。 如果任何領域都希望對用戶進行身份驗證，它將身份驗證令牌轉換為身份驗證信息對象。 如果該領域不希望這樣做，那么它將返回null。 開箱即用的Shiro框架過濾器會忽略請求中的PGP證書。 可用的身份驗證令牌無法保存它們，并且領域完全不知道PGP證書。 因此，我們必須創建：
- 身份驗證令牌來移動證書，
- Servlet過濾器能夠讀取證書，
- 驗證證書并將其與用戶帳戶匹配的領域。
我們的應用程序將有兩個不同的領域。 一種使用名稱標識帳戶和密碼來驗證用戶身份，另一種使用PGP證書兩者都進行。
在開始編碼之前，我們必須處理應用程序周圍的PGP證書和基礎結構。 如果您對設置的PGP證書不感興趣，
基礎設施
當用戶訪問Web應用程序時，他的Web瀏覽器可能會將PGP證書的副本發送到Web服務器。 證書由某個證書頒發機構或證書本身（自簽名證書）簽名。 Web服務器將其信任的證書列表保存在稱為truststore的存儲中。 如果信任庫包含用戶證書或對其進行簽名的授權證書，則Web服務器將信任用戶證書。 受信任的證書將傳遞到應用程序。
我們會：
- 為每個用戶創建證書，
- 創建信任庫，
- 配置Web服務器，
- 將證書與用戶帳戶關聯。
在portecle中創建和管理證書。 SimpleShiroSecuredApplication的示例證書位于src \ test \ resources \ clients目錄中。 所有商店和證書都具有通用密碼“秘密”。
創建證書
為portecle中的每個用戶創建自簽名證書：
- 創建新的jks密鑰庫：在File-> New Keystore中，選擇jks。
- 生成新證書：工具->生成密鑰對。 將密碼字段保留為空，證書將繼承密鑰庫的密碼。
- 導出公共證書：選擇新證書->右鍵單擊->導出，選擇“頭證書”。 這將創建.cer文件。
- 導出私鑰和證書：選擇新證書->右鍵單擊->導出，選擇私鑰和證書。 這將創建.p12文件。
.cer文件僅包含公共證書，因此您可以將其提供給任何人。 另一方面，.p12文件包含用戶私鑰，因此必須保密。 僅將其分發給用戶（例如，將其導入瀏覽器進行測試）。
創建信任庫
創建新的信任庫并將公共證書.cer文件導入到其中：
- 在文件->新密鑰庫中，選擇jks。
- 工具->導入可信證書。
配置Web服務器
Web服務器必須請求證書，并根據信任庫驗證它們。 無法從Java請求證書。 每個Web服務器的配置都不同。 Github上的Look at AbstractContainerTest類中提供了Jetty配置。
將證書與帳戶關聯
每個證書由序列號和簽署證書的證書頒發機構的名稱唯一標識。 我們將它們與用戶名和密碼一起存儲在數據庫表中。 數據庫更改位于db.changelog.xml文件中，有關新列，請參見changeset 3 ，有關數據初始化，請參見changeset 4 。
認證令牌
身份驗證令牌表示身份驗證嘗試期間的用戶數據和憑據。 它必須實現身份驗證令牌接口，并保存我們希望在servlet過濾器和領域之間傳遞的所有數據。
由于我們希望同時使用用戶名/密碼和證書進行身份驗證，因此我們擴展了UsernamePasswordToken類，并向其添加了證書屬性。 新的身份驗證令牌X509CertificateUsernamePasswordToken實現了新的接口X509CertificateAuthenticationToken ，兩者在Github上都可用：
Servlet過濾器
Shiro過濾器將用戶數據轉換為身份驗證令牌。 到目前為止，我們使用了FormAuthenticationFilter 。 如果傳入的請求來自登錄的用戶，則過濾器將允許用戶進入。如果用戶嘗試對自己進行身份驗證，則過濾器將創建身份驗證令牌并將其傳遞給框架。 否則，它將用戶重定向到登錄屏幕。
我們的過濾器CertificateOrFormAuthenticationFilter擴展了FormAuthenticationFilter 。
首先，我們必須說服它，不僅具有用戶名和密碼的請求，而且具有PGP證書的任何請求都可以被視為嘗試登錄。 其次，我們必須修改過濾器，以在身份驗證令牌中發送PGP證書以及用戶名和密碼。
方法isLoginSubmission確定請求是否表示身份驗證嘗試：
方法createToken創建身份驗證令牌：
@Overrideprotected AuthenticationToken createToken(String username, String password, ServletRequest request, ServletResponse response) {boolean rememberMe = isRememberMe(request);String host = getHost(request);X509Certificate certificate = getCertificate(request);return createToken(username, password, rememberMe, host, certificate);}protected AuthenticationToken createToken(String username, String password, boolean rememberMe, String host, X509Certificate certificate) {return new X509CertificateUsernamePasswordToken(username, password, rememberMe, host, certificate);}在配置文件中用CertificateOrFormAuthenticationFilter過濾器替換FormAuthenticationFilter：
[main] # filter configuration certificateFilter = org.meri.simpleshirosecuredapplication.servlet.CertificateOrFormAuthenticationFilter # specify login page certificateFilter.loginUrl = /simpleshirosecuredapplication/account/login.jsp # name of request parameter with username; if not present filter assumes 'username' certificateFilter.usernameParam = user # name of request parameter with password; if not present filter assumes 'password' certificateFilter.passwordParam = pass # does the user wish to be remembered?; if not present filter assumes 'rememberMe' certificateFilter.rememberMeParam = remember # redirect after successful login certificateFilter.successUrl = /simpleshirosecuredapplication/account/personalaccountpage.jsp將所有URL重定向到新的過濾器：
[urls] # force ssl for login page /simpleshirosecuredapplication/account/login.jsp=ssl[8443], certificateFilter# only users with some roles are allowed to use role-specific pages /simpleshirosecuredapplication/repairmen/**=certificateFilter, roles[repairman] /simpleshirosecuredapplication/sales/**=certificateFilter, roles[sales] /simpleshirosecuredapplication/scientists/**=certificateFilter, roles[scientist] /simpleshirosecuredapplication/adminarea/**=certificateFilter, roles[Administrator]# enable certificateFilter filter for all application pages /simpleshirosecuredapplication/**=certificateFilter自定義領域
我們的新領域將僅負責身份驗證。 授權（訪問權限）將由JNDIAndSaltAwareJdbcRealm處理。 只要PGP證書將用戶身份驗證為與用戶名/密碼相同的帳戶，這種配置就起作用。 否則，新領域返回的主要主體必須與JNDIAndSaltAwareJdbcRealm返回的主要主體相同。
我們的領域不需要緩存，也不需要可選接口提供的任何其他服務。 因此，我們只需要實現兩個接口：Realm和Nameable。
X509CertificateRealm僅支持帶有PGP證書的身份驗證令牌：
方法getAuthentcationInfo負責身份驗證。 如果提供的證書有效并且與用戶帳戶關聯，則領域創建身份驗證信息對象。 請記住，主要主體必須與JNDIAndSaltAwareJdbcRealm返回的主體相同：
@Override public AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {// the cast is legal, since Shiro will let in only X509CertificateAuthenticationToken tokensX509CertificateAuthenticationToken certificateToken = (X509CertificateAuthenticationToken) token;X509Certificate certificate = certificateToken.getCertificate();// verify certificateif (!certificateOK(certificate)) {return null;}// the issuer name and serial number uniquely identifies certificateBigInteger serialNumber = certificate.getSerialNumber();String issuerName = certificate.getIssuerDN().getName();// find account associated with certificateString username = findUsernameToCertificate(issuerName, serialNumber);if (username == null) {// return null as no account was foundreturn null;}// sucesfull verification, return authentication inforeturn new SimpleAuthenticationInfo(username, certificate, getName()); } 請注意，該領域具有兩個新屬性：trustStore和trustStorePassword。 兩者都是PGP證書驗證所必需的。 與其他任何屬性一樣，兩者都可以在配置文件中進行配置。
將新領域添加到Shiro.ini文件：
現在可以使用PGP證書登錄到應用程序。 如果證書不可用，則用戶名和密碼也可以使用。
應用程序源代碼在Github上的'certificates_as_alternative_log_in_method'分支中可用。
多個領域
如果配置文件包含多個領域，則將全部使用。 在這種情況下，Shiro嘗試使用所有已配置的領域對用戶進行身份驗證，并將身份驗證結果合并在一起。 負責合并的對象稱為身份驗證策略。 框架提供了三種身份驗證策略：
- 所有成功的策略
- 至少一項成功的策略 ，
- 第一個成功的策略 。
默認情況下，使用“至少一個成功的策略”，這非常適合我們的目的。 同樣，可以創建自定義身份驗證策略。 例如，我們可能要求用戶同時提供PGP證書和用戶名/密碼憑據才能登錄。
新要求：用戶必須同時提供PGP證書和用戶名/密碼憑據才能登錄。
換句話說，我們需要的策略是：
- 如果某些領域不支持令牌，則失敗，
- 如果某些領域無法驗證用戶身份，則失敗，
- 如果兩個領域認證不同的主體，則失敗。
認證策略是一個實現認證策略接口的對象。 在身份驗證嘗試之后和之前調用接口方法。 我們從“所有成功策略”（可用的最接近策略）創建“ 主要主體相同的身份驗證策略 ”。 在每次領域身份驗證嘗試之后，我們將比較主體：
@Override public AuthenticationInfo afterAttempt(...) {validatePrimaryPrincipals(info, aggregate, realm);return super.afterAttempt(realm, token, info, aggregate, t); }private void validatePrimaryPrincipals(...) {...Object aggregPrincipal = aggregPrincipals.getPrimaryPrincipal();Object infoPrincipal = infoPrincipals.getPrimaryPrincipal();if (!aggregPrincipal.equals(infoPrincipal)) {String message = 'All realms are required to return the same primary principal. Offending realm: ' + realm.getName();log.debug(message);throw new AuthenticationException(message);} }身份驗證策略在Shiro.ini文件中配置：
# multi-realms strategy authenticationStrategy=org.meri.simpleshirosecuredapplication.authc. PrimaryPrincipalSameAuthenticationStrategy securityManager.authenticator.authenticationStrategy = $authenticationStrategy最后，我們必須改回CertificateOrFormAuthenticationFilter的isLoginSubmission方法。 現在僅將具有用戶名和密碼的請求視為登錄嘗試。 證書不足：
@Override protected boolean isLoginSubmission(ServletRequest request, ServletResponse response) {return super.isLoginSubmission(request, response); }如果立即運行該應用程序，則必須同時使用證書和用戶名/密碼登錄方法。
該版本在Github上的'certificates_as_mandatory_log_in_method'分支中可用。
結束
此部分專用于Shiro領域。 我們創建了三個不同的應用程序版本，所有這些版本都可以在Github上獲得。 它們涵蓋了基本且可能是最重要的領域功能。
如果您需要了解更多信息，請從此處鏈接的類開始并閱讀其javadocs。 他們寫得很好，內容廣泛。
參考： Apache Shiro第2部分–我們的JCG合作伙伴 Maria Jurcovicova在This is Stuff博客上獲得的領域，數據庫和PGP證書 。
翻譯自: https://www.javacodegeeks.com/2012/05/apache-shiro-part-2-realms-database-and.html
apache shiro
總結
以上是生活随笔為你收集整理的apache shiro_Apache Shiro第2部分–领域，数据库和PGP证书的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 苹果电脑如何对优盘格式化吗(苹果电脑怎样
- 下一篇： jmeter数据库负载测试_JMeter