前言：BIEE11g的权限较之前10g版本有了较大的变化，最明显的地方就是构架上的变化，其与 Oracle Fusion Middleware Security 紧密的集成在了一起。
在开始之前先让我们来了解一些基本概念：
1、认证(Authentication)：所谓认证，就是校验用户名和密码是否正确，正确就通过认证，反之则不通过
2、授权(Authorization)：授权就是给用户赋予相应的权限，比如userA是否可以查看报表B。
用户登录BIEE的过程，就包含这两个过程；首先用户提供用户名和密码交由BIEE校验，如果正确才会进行授权，否则直接提示用户名密码错误。要记住，认证和授权是分离的！
在10g的时候，默认情况下(不考虑LDAP和外部表),用户和组的信息是存在RPD里的。而11g则存放到了与之关联的Weblogic域内置LDAP服务器里了。同时，在10g的时候存在用户和组(Group)的概念，11g则新引入了角色的概念(Role)，并将BIEE内部权限的授予对象变成了现在的用户和角色(Role)。
简单来说，你可以把11g中的角色(Role)等于同10g的组(Group)，那么11g的组(Group)呢？他又是干什么的呢？其实这个组是位于内置LDAP服务器里的组，其对BIEE来说不可见。组和角色的分离有什么好处呢？
1、可以在不变更企业已有LDAP服务里用户和组的情况下，将它们映射到BIEE的角色上。因为LDAP服务器通常是全局的，多系统共用的，没必要为BIEE权限的需求而到LDAP里去新建组。另外，你也可以在不改变角色在BIEE内部授权的情况下，通过重新映射组和角色的关系实现认证源(LDAP服务器)的迁移。
2、便于成批添加用户到角色里。由于BIEE的授权对象是用户和角色，虽然用户可以直接挂载到角色上，但是比起把一百个用户添加到一个角色下，和把这一百用户所属的组添加到角色上，哪个更容易？
11g组和角色的关系如下图所示：
这是安装完毕之后默认的权限配置情况,可以看到User1,User2,User3属于BIConsumers这个组，BIConsumers这个组属于BIConsumer这个角色，依此类推。另外还要注意到角色之间是有继承关系的，而组之间是没有继承关系的。
组是存放在Weblogic的内置LDAP服务器里的(为了方便，通常我们可能会说其存在console里的，因为我们是使用console来管理weblogic服务器)
角色是存放在Policy Store里的(默认是基于xml文件的，名叫system-jazn-data.xml)，其通过 Oracle Enterprise Manager 来进行管理的(同样的，通常我们也会说其是存放在em里的)。
Note:
console的访问方式 http://xxxx:7001/console
em的访问方式 http://xxxx:7001/em
说的这里，不知道大家有没有疑惑，BIEE是怎么知道用户A应该能看哪些报表，不能看哪些报表的呢？怎么让用户B能有新建分析的权限，而用户A没有呢？
这里要引入一个安全策略(Security Policy)的概念(通俗的讲就是权限)。
这个策略主要有如下三块：
1、RPD：RPD里可以定义字段和表的权限，比如用户A能不能访问表A；这些权限在你访问BIServer的时候会被应用。
2、Catalog:用户能看哪些报表，能使用哪个功能都是在Catalog里定义的；这些权限在你访问Answer和Dashboard的时候会应用。
3、PolicyStore：这里面定义了哪些用户或者角色可以使用BI Server\BIP\RTD的哪些功能；比如什么用户可以使用Admin Tools联机打开RPD。
所谓的策略，其实就是一些记录，只是这些记录存储的位置各不相同。如下图所示：
细心的朋友可能会发现图中有一个Credential
Stores的东西我们还没提到，它是干什么的呢？顾名思义，其就是用来存放一些凭据(比如密码)的，大家都知道11g的RPD是有密码的，这个密码是我们自定义的，那我们把这个RPD上传到服务器之后，服务器怎么能打开这个RPD呢？它也得需要密码啊，既然需要，那么就得有一个地方来存储这个密码吧？
没错，这个密码就是存放在Credential Stores里的。同样的还是一些系统用户的密码也是存放在这里的，具体的我们在之后的帖子里在讲解。
下面我们来串一下整个登录过程，回答一下前面的问题，结束今天的内容。
假设已知用户A属于角色ROLEA，且我们只对角色进行了授权，ROLEA可以查看Revenue By Year这张报表(ROLEA可以查看这张报表的记录就存在与报表同名的*.atr文件中)。
当用户A登录BIEE的时候，BIEE会去Policy Store 查到其属于ROLEA(用户所属的角色信息，可以在BIEE的我的帐户菜单中看到)，并记录到session的安全变量中；登录成功之后
用户A点击Revenue By Year这张报表的时候，系统就会去查询这张报表的安全策略，发现里面有一条记录写着ROLEA可以访问这张报表，那么用户Ａ就可以看到报表的内容了，反之则不能。
今天我们就来讲讲11g的默认权限(即软件安装完毕之后BIEE的一些初始化权限配置)。
不知道大家还记不记得，在10g的时候，RPD中存在一个名叫Administrator的用户，这个用户就是管理员用户，其拥有最高权限。
到了11g，由于架构的变化，帐号密码之类的信息已经从RPD中移到了Weblogic内置的LDAP服务器里了。
且用户名默认为weblogic，密码则在安装过程中指定。
如果我们想要修改用户名密码、增删用户，那么我们就得使用Weblogic的控制台，这里一个基于web的管理程序，用于管理Weblogic服务器
默认访问路径为：
http://主机名:7001/console
注：使用weblogic及安装过程中指定的密码登录
默认的用户、组及角色如下图所示：
大家可以看到组和角色之间是有对应关系的
组BIConsumers挂在角色BIConsumer之下
组BIAuthors挂在角色BIAuthor之下
组BIAdministrators挂在角色BIAdministrator之下
这个“挂”的操作是在EM中完成的
注：至于为什么引入组和角色，大家可以参见我之前的帖子。
既然组和角色之间的关系已经定义好，那么我们在新建用户，或者想更改用户当前的权限的时候，就可以只用在console把将用户加到对应的组里就可以了。
如果现有的配置满足不了我们的需求，我们才会考虑在console中新建新的组，并将其“挂”到相应的角色(可以根据需要新建或利用现有角色)上；最终在BIEE系统中，我们只能对用户或者角色进行授权。
下面我们来看看应该如何进一些用户管理方面的常规操作吧。
1、新建用户
登录console，点击左侧的“安全领域(Security Realms)”然后选择“myrealm”－“用户和组(Users and Groups)”选项卡，如下图所示：
点击左下角的“new”按扭，就可以新建用户了；同理，切换到“组(Groups)”标签，就可以新建组了，具体过程大家可以按提示操作即可。
2、给用户分配组
创建好的用户就会出现在第1步“用户(Users)”标签下面的列表中：
点击我们想要分配组的用户名，进入用户属性设置界面，可以看到有4个标签
可供我们修改的主要是“密码(Passwords)”和“组(Groups)”两个标签，这里先选择组标签，
然后勾选我们需要分配的组，接着点右中间的右箭头，然后点击“save”，就可以把用户加入该组之中。
3、修改密码
在第2步的界面中，选择“密码(Passwords)”标签，即可修改用户的密码。建好了用户和组，接下来我们需要创建角色了。虽然角色不是必须的，但是通常来说我们都是对角色而不是用户来进行授权。
为什么？
因为角色(用户)在报表上的权限是直接写到对应报表同名的atr文件中的，如果有100个用户需要访问某一张报表，按照用户授权的方式我们就需要对该报表操作一100次，以完成对100个用户的授权；而采用角色的方式，我们可能只需要创建一个角色，然后在报表上对该角色授一次权，最后把100个用户挂到这个角色上就可以了。
看到这里，也许有朋友会问了，虽然后者你只授一次权，但是你需要把100用户添加到这个角色里，你得添加100次啊。没错，不过把用户添加到角色里就相对来说要容易得多了。
因为虽然默认情况下BIEE是使用的Weblogic内置的LDAP作为认证源，且只能通过console来管理用户(console用户的管理功能太薄弱)，但是实际上在真正的企业应用环境中，我们都会将BIEE与企业已有的认证源(企业已有的LDAP服务器或者存放了用户信息的关系数据库)进行集成，而这些认证源中通常都会有组的概念，且可以支持批量添加用户到组的操作，我们只需简单把组和角色做一个映射就可以完成用户到角色的关联。