Shiro 被设计成能够在任何环境下工作，从最简单的命令行应用程序到最大的的企业群集应用。由于环境的多样性,使得许多配置机制适用于它的配置。
一、 许多配置选项
Shiro的SecurityManager实现及所支持的组件都是兼容JavaBean的。这使得Shiro几乎能使用任何配置格式，如regular Java，XML(Spring, JBoss, Guice,等等)，YAML，JSON，Groovy Builder markup，以及更多的配置。
二、 可编程配置
创建一个 SecurityManger 并把它提供给应用程序的绝对的最简单的方法是创建一个 org.apache.shiro.mgt.DefaultSecurityManager 并把它链到代码中。
三、 安全管理器对象图
Shiro 的 SecurityManager 实现实质上是一个特定安全的嵌套组件中的模块化对象图。因为它们也是兼容 JavaBean 的，你可以调用任何嵌套组件的 getter 和 setter 方法来配置 SecurityManager 以及它的内部对象图。
例如，如果你想配置 SecurityManager 实例来使用自定义的 SessionDAO 来定制 Session Management，你可以通过嵌 套的 SessionManager 的 setSessionDAO 方法直接设置 SessionDAO：
通过使用直接方法调用，你可以配置 SecurityManager 的对象图的任何部分。
但是，程式化定制过于简单，它并不能代表大多数现实世界的应用程序的理想配置。以下是程式化定制可能不适合 你的几点原因： 它需要你了解和实例化一个直接实现。这将会更好，如果你不需要了解具体的实现和在哪里可以找到它们。 由于 Java 的类型安全性，你需要转换通过 get*方法获取的对象来得到它们具体的实现。如此多的转换是丑陋 的，冗长的，并使你和实现类紧密连接起来。
SecurityUtils.setSecurityManager 方法调用在一个 VM 静态单例中实例化 SecurityManager 实例，VM 静态单例 在给许多应用程序带来好处的同时，也会引发一些问题，如果多个启用 Shiro 的应用程序在同一个 JVM 中运行。如果该实例是一个应用程序单例，而不是一个静态内存引用就再好不过了。 每当你想改变 Shiro 配置时，它需要你重新编译你的应用程序。 然而，即使有这么多警告，直接的编程操作方法在内存受限的环境中仍然是有价值的，如智能手机应用。若你的应用程序不在一个内存受限的环境下运行，你会发现基于文本的配置要更容易使用和阅读。
四、 ini配置
大多数应用程序反而从基于文本的配置受益，能够独立地修改源代码，甚至让那些不熟悉 Shiro 的 API 的人能够更 容易理解。
为了确保一个基于文本的通用标准配置机制能够在所有环境下以最小的第三方依赖工作，Shiro 支持 INI 格式来构建 SecurityManager 对象图及其支持的组件。INI 易于阅读，易于配置，且设置简单，适合大多数应用程序。
(1) 来自ini实例的安全管理器
如果你需要，INI 配置也可以通过 org.apache.shiro.config.Ini 类使用编程方式创建。Ini 类的功能与 JDK java.util.Properties 类相似，但通过 section 名称，它同时还支持分割。
现在，我们知道如何从 INI 配置构建出一个 SecurityManager 了，我们看看到底是如何定义一个 Shiro INI 配置的。
（2) INI Sections
INI 基本上是一个文本配置，包含了由唯一命名的 section 组织的键/值对。键只是每个 section 唯一，而不是在整个 配置中（与 JDK 属性不同）。不过每个 section 都可以被看作单一的属性定义。 注释行能够以散列字符（# - 也就是"hash","pound"或"number"符号）或分号（";"）开始。
以下就是shiro能够理解section的例子:
[main]
[main] section 是你配置应用程序的 SecurityManager 实例及任何它的依赖组件（如 Realms）的地方。 配置对象实例，如 SecurityManager 或任何它的依赖组件，通过使用 INI 听起来是一件困难的事情，我们仅能使用名 称/值对。但通过一点点约定和对对象图的理解，你将会发现你可以做很多事情。Shiro 使用这些条件来简单却相当 简洁的配置机制。 我们往往喜欢把这种方法称为“穷人的”依赖注入，虽然没有完全成熟的 Spring/Guice/JBoss XML 文件强大，但你将 会发现它能够完成许多事情却没有太多的复杂性。当然那些其他的配置机制也同样可用，但它们不是使用 Shiro 所 必需的。
为了激起你的欲望，这里有一个有效的[main]配置的例子。我们将在下面讨论它的细节，但你可能会发现，仅凭直 觉就能明白很多事情是怎么回事：
这一行实例化了 com.company.shiro.realm.MyRealm 类型的新的对象实例，并使该对象使用 myRealm 名称，以供进 一步的引用和配置。 如果该实例化的对象实现了 org.apache.shiro.util.Nameable 接口，则 Nameable.setName 方法将会在拥有该名字（在 本例中是 myRealm）的对象上调用。
注意:
每个对象的实例化以及每个值得分配都是按照它们在[main] section 中出现的顺序来执行的。这些配置行最终转化成 一个 JavaBean 的 getter/setter 方法调用，因此，这些方法以同样的顺序被调用！ 当你编写你的配置时，请记住这点。
[users]
[users] section 允许你定义一组静态的用户帐户。这在大部分拥有少数用户帐户或用户帐户不需要在运行时被动态地 创建的环境下是很有用的。以下是一个例子:
a.Automatic IniRealm :
仅定义非空的[users]或[roles] section 将会自动地触发 org.apache.shiro.realm.text.IniRealm 实例的创建，并使它在 [main] section 中可用且名为 iniRealm。你可以像上面所描述的其他对象一样来配置它。
b.Line Format
在[users] section 中的每行都必须保证是下面的格式：
username = password, roleName1, roleName2, …, roleNameN
在等号左边的值是用户名。
在等号右边的第一个值是用户的密码，密码是必须的。
任何在密码后用逗号分隔的值都是分配给该用户的角色名。角色名是可选的。
c.Encrypting Passwords
如果你不想[users] section 中密码是纯文本的，你可以使用你喜爱的散列算法（MD5，Sha1，Sha256，等等）来进行加密，并使用生产的字符串作为密码值。默认情况下，密码字符串是 16 进制编码，但可以使用 Base64 编码代替 16 进制编码来配置（见下面）。
一旦你指定了文本密码散列值，你得告诉 Shiro 这些都是加密的。你可以通过配置在[main] section 中隐式地创建 iniRealm 来使用合适的 CredentialsMatcher 实现来对应到你所指定的哈希算法：
你可以像任何其他对象一样在 CredentialsMatcher 上配置任何属性，以反映你哈希策略，例如，指定 salting 是否被使用或需要执行多少次哈希迭代。请参见 org.apache.shiro.authc.credential.HashedCredentialsMatcher 的 JavaDoc 来更好的理解哈希策略，如果它们对你可能有用的话。
例如，如果你的用户密码字符串是 Base64 编码而不是默认的 16 进制，你可以指定说明：
[roles]
[roles] section 允许你把定义在[users] section 中的角色与权限关联起来。另外，这在大部分拥有少数用户帐户或用户 帐户不需要在运行时被动态地创建的环境下是很有用的。以下是一个例子：
Line Format
在[roles] section 中每个配置行必须定义一个映射以下格式的角色到权限的键/值： rolename = permissionDefinition1, permissionDefinition2, … , permissionDefinitionN permissionDefinition 是一个任意的字符串，但大多数人将会使用符合 org.apache.shiro.authz.permission.WildcardPermission 格式的字符串，为了易用性和灵活性。请参见 Permissions 文档 获取更多关于 Permissions 及你如何从它们受益的信息。
Internal commas
请注意，如果一个独立的 permissionDefinition 需要被内部逗号分隔（例如，printer:5thFloor:print,info），你需要用户双引号环绕该定义，以避免错误解析： "printer:5thFloor:print,info"
Roles without Permissions
如果你有不需要权限关联的角色，你不需要在[roles] section 中间把他们列出来，如果你不想的话。只需定义在[user] section 中定义角色名就足以创建尚不存在的角色。
