转载
最近了解到AME 的东西，很迫切，先转载一篇
[@more@]
Oracle User Management FAQ翻译及学习笔记
写在前面
本文主要是翻译的英文版的Oracle User Management FAQ,连接为http://www.oracle.com/technology/products/applications/security/OracleUserManagementFAQ.htm或者是Metalink的290525.1,增加了一部分自己学习的记录,错误肯定有很多,请英文好的朋友尽量参看原文.
我会陆续的更新和添加本文,做为自己学习的记录和参考,最新版请参考http://docs.google.com/Doc?id=dd9hpwxq_13d8q3dbgt 或者malufeng#gmail.com索取.
有错误的地方烦请发送到malufeng#gmail.com告知,多谢.
转载请保持本文的完整性,做人要厚道 ^_^,多谢.
更新历史
2009-03-05 初始版本
1.什么是基于角色访问控制(Role Based Access Control(RBAC))?
基于角色访问控制是National Institute of Standards & Technology (NIST)支持的ANSI标准(ANSI INCITS 359-2004)[笔记:ANSI=American National Standards Institute,相当于美国的国标].
在Oracle EBS的11.5.10版本中,Oracle用户管理(Oracle User Management)非常接近的按照此标准提供一个RBAC的模型.
RBAC标准支持的用户访问控制不再着眼于单个用户,而是基于用户在组织中所扮演的角色来实现的.
采用RBAC的好处有
1.降低管理用户访问权限的成本
2.合理的设置和实施用户访问安全策略
3.根据用户的不同的工作职能,结构化用户的访问控制
RBAC是对Oracle Applications现有的访问控制方式一种增强和补充.它提供一种新的方式来组织系统的数据安全策略和既存的功能安全(通过角色(Role)来实现).现阶段Oracle Application的安全权限是基于独立的一个一个的用户进行管理的,也就是说,通过直接赋予每一个用户不同类型的权限来进行管理的.举例说,一个在Support Agent职位上的人,必须通过赋予他多种职责和其他许多不同类型的访问控制权限才能使其在系统里进行工作.
通过利用RBAC方式,不再需要对用户直接赋予低层次的权限和职责,而是通过赋予角色(Role)来隐式的进行继承和分配.角色(Role)定义中,可以包含职责和其他角色(Role)(通过角色(Role)继承实现),当然也可以包含低层次的权限(功能)和数据安全策略(data Security poilce).
通过把所有的权限赋予角色(Role),后续的工作就可以通过一次性的设置来完成,如果系统中有一个批量的权限修改,用户只需用更改角色中的权限或者角色的继承层次,系统中被分配了该角色的用户权限就会马上同步更新.
笔记:通俗的理解,角色这个概念在很多系统中都有,可以理解为企业中职位的抽象,比如说"销售经理",可能有好多个人都是销售经理,但他/她们的角色都是一样的.如果公司录用了一个新的销售经理,在RBAC中,只需要赋予一个定义好的"销售经理"角色给该用户就可以,不用很繁琐的赋予每一个职责.删除所有销售经理的一个职责时,RBAC这种方式更显简洁,不会有遗留和繁琐的逐个用户操作.
2.角色(Role)和职责(Responsibility)有什么不同?
职责可以被认为是一种特殊的角色,该角色相当于一个在应用中可以浏览的菜单集合.因此,职责可以宽泛的代表程序本身,相反,角色可以决定应用的那一部分(或者说数据)可以被用户访问.这代表了在应用中职责定义的一种改变.在之前的版本中,职责不仅用来定义应用的导航菜单,而且同时代表了应用里的权限.按照这样的职责定义,通常需要创建很多相似的职责,仅仅只是因为这一组人在数据和功能访问上存在细微的差别.随着职责越来越多,这种做法增加了许多额外的成本.
Oracle Application根据Role Based Access Control (RBAC)在ANSI INCITS 359-2004中关于角色的定义:'一个在特定组织中的职能或者功能,拥有与其相关联的授权和职责,可以通过分配来授予一个用户(a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role.)'
角色的定义决定了那些应用(职责)以及那些数据和功能在此应用中可以被一个用户访问.
通过利用RBAC方式,不再需要对用户直接赋予低层次的权限和职责,而是通过赋予角色(Role)来隐式的进行继承和分配.角色(Role)定义中,可以包含职责和其他角色(Role)(通过角色(Role)继承实现),当然也可以包含低层次的权限(功能)和数据安全策略(data Security poilce).
通过把所有的权限赋予角色(Role),后续的工作就可以通过一次性的设置来完成,如果系统中有一个批量的权限修改,用户只需用更改角色中的权限或者角色的继承层次,系统中被分配了该角色的用户权限就会马上同步更新.
笔记:关于Role的定义,这句英语"a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role"一直翻译的觉得不顺口.有啥意见和建议,希望可以分享给我.
3.角色(Role)和组(Group)有什么区别?
为了避免混淆,在Oracle Applications 中角色(Role)和组(Group)有不同的定义,就像我们之前描述过的,我们使用标准的RBAC的参考模型里面的角色(Role)定义,就是:"一个在特定组织中的职能或者功能,拥有与其相关联的授权和职责,可以通过分配来授予一个用户(a role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role.)"
组(Groups)是指一些用户的普通集合,或者还有一些其他类型的组,这些组由于某些特定的目标而成立,但不一定必须是以访问权限为目的而成立.在当前版本的Oracle Application中,有很多不同来源的组(Group).有许多但不仅仅局限于此的例子,
比如,在Oracle HR模块中定义的角色(Role)和职位(Position),在TCA(Trading Community Architecture)中定义的团体成员(Group Parties),还有在资源管理器(Resource Manager)中定义的资源组(Resource Groups).
当然,以获取访问权限为目的,我们也可以构成一个组(Group),但是,如果放在讨论应用安全的背景下,只有角色(Roles)可以代表一个组织下的工作职能,并且可以关联在此组织基础上的访问控制权限.因此,从以应用的安全为目这个角度来讲,我们就可以看出组(Groups)和角色(Roles)明显的不同.
RBAC实施的一个重要特性或者方面是它可以影响和带动在Oracle Application已经实施的各种各样不同的组(Groups)拥有RBAC的特性.比如说下面的组就可以具有这样的特性,在Oracle HR模块中定义的角色(Role)和职位(Position),在TCA(Trading Community Architecture)中定义的团体成员(Group Parties),还有在资源管理器(Resource Manager)中定义的资源组(Resource Groups).组(Groups)和组成员(Group memberships)都是在各自的应用(Application)中维护的.通过Oracle用户管理(Oracle User Management),客户可以把权限(permissions)赋予这些外部管理的组(externally managed groups).在将来,这些组可以被层次或者等级化,可以允许客户通过角色继承(role inheritance)为组分配角色和职责.因为角色的引入,权限的管理成本将会显著的降低,比如说随着用户职位或者组的变更,其对应的权限和职责会自动的更新.
4.什么是功能安全(Function Security)和数据安全(Data Security)?
在Oracle Application中,最基本层面的访问控制是功能安全,功能安全可以限制用户访问系统中单个菜单和菜单的某些选项.同时,它也可以用来控制是否可以访问页面中的某些小工具(通常,是以图片的形式展现在页面中,类似于ICON等).这样存在于系统中多种多样的元素或者项目,每一个都可以叫做功能(Function)或者权限(Permission).使用订单(Order Entry)页面作为例子,功能安全可以控制你是否可以创建一个新的订单,甚至你是否可以访问这个页面.
在Oracle Application中,下一个层面的访问控制就是数据安全(Data Security).它和功能安全结合在一起发挥作用,数据安全提供了更进一步的控制,它控制一个用户在Oracle Application中可以访问那些数据以及可以如何操作这些数据.使用数据安全,举一个例子,你可以控制一个订单管理员在Oracle的订单管理系统里可以更新那一部分订单.
数据安全策略用来限制在一个指定的业务对象(Business Object)上可以进行的动作和操作.数据安全策略可以在下列的访问中得到反映:
所有的实例(All Instances) -- 一个对象的所有实例本质上就是数据库里该对象的所有记录.举个例子,假如我们有一个对象"inventory item"在数据库中,为该对象的所有的实例创建一个数据安全策略,可以允许我们访问已经编录在数据库的每一个单独的库存项目.
一个实例集(An Instance Set) - 一个实例集是指一个对象中相关联的一些数据的实例集合.对应于数据库,相当于数据记录的集合.该集合通过指定在对象属性上的谓词来限定.谓词一般表现为SQL语句的Where条件,可以选择使用VPD(Virtual Private Database)策略来实现.使用我们前面提到的对象做为例子,所有保质期为7天的库存项目就可以做为一个实例集.
一个具体的实例(A Specific Instance) - 一个具体的实例通常表现为数据库中的一条记录, 通常通过该对象的主键来进行确定. 还是上面的例子,我们可以通过输入唯一的库存项目序列号,这样从数据组中就只能返回仅有的一条记录.
对于功能和数据安全,权限可以通过下列三种中的任意一种方式赋予.权限可以赋予系统中的所有用户(但是不包含使用Guest)访问系统的用户.权限可以赋予具体的某一个人.以及,权限可以赋予一组人,比如说,所有拥有Sales Manager角色的用户.
举例说明在Oracle用户管理中带有数据范围的权限分配
1.所有实例:重置<所有用户>的密码
2.实例集:重置<我的组织之内的员工>的密码
3.具体实例:重置<John Doe>的密码
在<>里面的内容表示数据范围
5.在Oracle EBS的schema中存放的任何数据上都可以定义数据安全策略吗?
虽然管理员可以为EBS的数据定义数据安全策略,但是单独的EBS应用(Application)必须强制执行数据安全策略.那些实施了数据安全的应用将强制执行数据安全策略.
笔记:也就是说这个是按照应用来分的,比如说HR实施了Oracle Data Security.那它就可以使用数据安全策略.
6.数据安全(Data Security)和Oracle Label Security有区别吗?
是的,它们是不同的.Data Security限制用户通过选择菜单或者菜单项来访问数据并且会显示在屏幕上的数据,这个是通过Data Security Policies来实现的.Oracle Label Security帮助数据库管理员基于Oracle Sensitivity labels和clearances来实现对数据库表行级别的数据访问控制.Oracle EBS可以使用这一个特性来实现在EBS数据基于Label的数据安全访问控制策略.
关于如何在EBS中使用Oracle Label Security,请访问Metalink Note:234599.1
笔记:也就是说这两个互不相干,可以通过各自的特性为Oracle EBS服务,Oracle Data Security侧重的是界面上数据的显示,而Oracle Label Security侧重的敏感数据的安全.
7.什么是授权(Grant)或者权限分配(Permission Assignment)?
权限分配体现了通过Role对用户的访问授权.Oracle Application中的权限分配也叫做授权.权限分配可以通过以下两种方式中的任意一种进行授权.权限分配可以提供访问特定数据集合的权限或者可以提供访问特定的应用程序功能集合的权限.
Oracle Application把那些处理业务对象的权限分配叫做数据安全或者数据安全策略.我们一般把这种类型的权限分配叫做"约束".你可以使用数据安全用来保护某些特定数据对象的某一方面的安全.比如说,你想对作者为马克吐温的书做访问控制.
Oracle Application把那些处理程序功能方面的权限分配叫做功能安全(Function Security).我们一般把这种类型的权限分配叫做"非约束".当你需要在应用中考虑菜单,页面或者其他工具的安全性,你就需要使用功能安全.比如说,你需要把一个管理菜单的集合赋给选定的一组用户时,你就需要功能安全.
当创建一个授权分配的时候,Oracle Application把授权的主体叫做授予者(grantee).授予者表明谁被赋予了权限.授予者可以是下面三种类型中的一种:
1. 一个角色或者组 -包含在该组或者角色里面的所有用户
2.一个具体的用户 -比如说,Joe Smith
3.所有的用户(全局)-将会应用到系统里的所有用户,除了Guest.
8.权限分配(Permission Assignment)和角色(Role)有什么不同?
RBAC参考模型定义权限(permission)为:"一个审批或者授权使得可以在一个或者多个被RBAC保护的对象上进行操作."在过去,我们一般把一个权限看做成一个可以在对象上进行操作的功能.比如:调用Service Request表单,更新订单,
审批费用报表,查询客户.
许多权限可以做成权限集(Permission Sets),权限集可以通过权限分配授权给用户或者角色.因此,权限分配可以反映用户或者角色的授权.权限分配可以通过下面的两种方法中的一种进行授权,权限分配可以提供访问一个限定的数据集或者是一个应用中的一个功能集.
9.菜单(Menus)和权限(Permission)有什么区别?
我们把许多权限做成一个权限集,定义权限集有两个目的:做为菜单集或者权限集.每一个权限集都可以包含其他的权限集.
定义菜单是为了浏览或者一组用来进入功能区的UI(User Interface)页面.用户通过选择职责访问菜单,每一个菜单选项对应一个权限.而这样的每一个权限都可以有选择性的做为菜单的一部分或者职责的一部分对用户进行分配.那些没有做为菜单或者职责的部分被分配的菜单项,将不会被显示在页面,除非这些权限被逐个或者分散的授予给该用户.
权限集授予用户或者角色是独立于菜单或者职责的,权限集授予一个用户的目的是为了激活一些菜单项或者其他操作(功能).这些菜单项或者操作(功能)对于分配了这个菜单或者职责的所有用户来说并不是都应该有全部权限的.权限集通过权限分配(Permission Assignment)授权给用户,或者在Oracle Application我们一般叫做授权(Grants).
10.什么是角色类别(Role Categories)以及应该如何使用它们?
角色类别是一种很有用的用来管理角色和职责的分类方法.管理员可以创建类别来归类角色和职责,这样,当有很多角色和职责的时候,就很容易查询和搜索.Oracle User Management默认提供的类别有:安全(Security),管理(Administration),和杂项(Miscellaneous).
11.什么是角色继承层次(Role Inheritance Hierarchies)?如何被创建?
角色可以被包含在角色继承层次中.当角色包含在继承层级中,这些角色的所有职责和权限都会被授予用户.
Oracle Application RBAC模型支持通用角色继承,也就是说,所有的角色都可以有许多上级角色或者下级角色.
角色继承层次可以在Oracle用户管理的角色和角色继承(Role&Role Inheritance)界面中创建.管理员可以使用添加角色(Add Role)来内嵌角色.这种内嵌的结果就是上级角色继承子角色.这种做法也同样适用于从其他源系统(比如在资源管理器里面定义的资源组)为组(Group)创建角色继承.
12.所有的外部组(external groups)都可以被继承吗?
不是,为了使管理员可以利用已经存在于Oracle Application中各种各样不同的组(Groups)(比如,在Oracle HR模块中定义的角色(Role)和职位(Position),在TCA(Trading Community Architecture)中定义的团体成员(Group Parties),还有在资源管理器(Resource Manager)中定义的资源组(Resource Groups)),拥有该组(Groups)的应用(Application)必须支持可以使用Workflow Directory来维护该组成员的增量同步.当然,拥有该组(Groups)的应用(Application)必须在Workflow Directory注册该组并且为可继承的.这样的话,客户就可以通过角色继承来分配角色和职责给该组.
13.什么是委托管理(或者委派管理)(Delegated Administration)?
委托管理为传统的系统管理员提供了一个能力或者方法,可以通过委托一部分用户管理的权限给那些更接近最终用户的人员.这些本地的管理员可以管理一部分人,当然仅限于他们功能范围内的访问权限.
Oracle Application的访问控制允许管理员在企业内部或者企业外部可以在任何层级进行委托.内部,客户可以在分公司甚至部门层次进行委托管理,更近一步,也可以委托外部组织里面的人管理该外部组织的人员.
14.怎么自定义委托管理策略(delegation policies)?
委托策略是做为数据安全策略(data security policies)被定义的.委托管理有一部分是我们定义的数据安全策略集,我们把这个数据安全策略集叫做管理权限(Administration Privileges).
管理权限(Administration Privileges)决定了委托管理员可以管理那些用户.管理权限有三个方面:角色,人员,和组织.每一个权限都是独立授权.当然这三个面共同为委托管理员提供一个完整的能力集.在Oracle用户管理的角色和角色继承(Role & Role Inheritance)界面,这些权力都可以和角色定义一起被定义.
15.什么是注册流程(Registration Process)?
注册流程(Registration Processes)使得组织可以提供给最终用户一个根据自己的资格请求不同级别访问的方法.注册流程为帐户维护和角色分配提供合理的流程,从而简化了系统管理员在这方面的工作.注册流程也允许按照需要客户化审批流程,通知,身份验证和资格验证.
Oracle用户管理支持三种类型的注册流程
帐户创建(自助)(Self-Service Account Requests)- 用户可以通过它自助创建(申请)新账号.举例说,一个客户必须注册一个帐户才能在在线商店里购买物品.当客户完成注册流程,客户就会得到一个账号和一些访问该站点所必须的一些基本角色(Role).这种类型的注册流程也提供身份验证,这样就能验证申请者的身份(通过电子邮件要求一个确认)在该流程完成之前.如果申请者在规定的时间内没有回复确认,那么申请将会被自动拒绝.
附加访问(Requests for Additional Access)-Oracle用户管理提供一个访问需求工具,这样一个已经存在系统中的用户就可以申请一些附件的权限.用户只能申请那些于自己当前角色比较符合的附加角色.举例来说,你可以在Oracle User Management中设定所有拥有"员工(Employee)"角色的用户都有资格注册申请'销售代表(Sales Representative)'角色,同时所有的客户(Customer)都没有资格申请这个角色.尽管如此,所有的人都可以注册登陆iRecruitment去查找职位和工作.系统管理员分配一个角色给用户,在本质上就是基于用户行为的一次注册请求,如果定义了对应角色的附件访问注册流程,就可以调用该注册流程来完成此工作.
帐户创建(管理员)(Account Creation by Administrators)--使得管理员(包括委托管理员)有能力创建用户.每一个帐户创建注册流程对那些指定的管理员都是可用的.
笔记1:R12的User Management中,附加访问被分为附加访问(自助)和附加访问(管理员).
笔记2:附加访问申请有点类似于把过去管理员一种被动的分配变成用户主动的去获得.举例来说,假设ERP100社区(http://www.erp100.com/)有一个版面叫做"老会员交流区",而只有成为"老会员"的用户才能访问这个版面.而成为或在想拥有"老会员"这个角色,过去,我们可以要求管理员为自己分配,现在如果把这个做成[附加访问申请],那么用户可以自己去点击申请来获得次角色,以便访问"老会员交流区"这个版面.当然在点击申请这个界面,可能就需要判断申请人是否有资格(参加问题21),以及可以告知用户某些该版的注意事项等.这样对于有许多用户的系统,管理员的负担肯定会减轻,而且这样的用户自己申请的方式和系统自动或者管理员分配的方式相比较,用户对该角色的认知更加深刻.
注册流程有很多的好处,对于申请新帐户和附加访问权限申请,它都提供合理简洁的流程,同样对管理员也是一样的.注册流程带给每个应用一样的基础架构来满足各种各样的注册需求,同时为所有EBS里面的应用提供一个统一的管理体验.
你可以定义专门的注册流程(包括独立的用户界面)去收集特定的信息做为你所在组织的策略的一部分.每一个注册流程包含以下信息
注册的类型
注册成功后赋给用户的角色
注册流程的目的描述
可选的用户注册界面用来收集帐户或者附加信息
一个用来审批,确认,拒绝和身份认证的工作流(workflow)
审批管理事务类型,事务类型代表了在运行的时候会被解释/使用的一组审批路径规则.
一个有资格可以申请附件访问的用户组.(只适用于附加访问申请的注册流程)
如果需要身份认证(identify verification)(只适用于自助帐户创建),身份验证会在请求完成之前确认申请人的身份,一封电子邮件会发送到申请人提交的电子邮箱,如果申请人没有在规定的时间内回复此邮件,那么该申请会被自动拒绝.
通过管理员的帐户创建注册流程,本地管理员(local administrators)可以注册人员或者创建帐户.
Oracle用户管理预安装了下面的注册流程做为例子:
个人用户注册(Individual User Registration (UMX_EXT_INDIVIDUAL))-该注册流程允许外部的独立用户(客户或者任何与组织或者商业实体没有关系的人)可以自助注册一个帐户.该注册流程的类型是帐户创建(自助).
外部组织联系(External Organization Contact (UMX_EXT_ORG_CONTACT) )-该注册流程管理员可以用它来注册或者创建一个代表外部的组织(比如供应商,客户等)的用户.该注册流程需要管理员拥有组织管理权限(Organizations Administration Privileges).该注册流程的类型是帐户创建(管理员).
员工注册(Employee Registration (UMX_EMPLOYEE))-该注册流程允许那些在HR系统中存在的内部员工去注册帐户.员工使用邮件地址和员工号做为认证信息.用户名将根据用户名策略(比如最简单的:邮箱地址)生成.该注册流程的类型是帐户创建(自助).
Oracle用户管理额外的封装了既存人员帐户创建(Account Creation for Existing Person (UMX_USER_4_EXISTING_PERSON) )注册流程,可以在User Administration页面使用.所有想为既存人员创建帐户的管理员都可以使用该注册流程.该注册流程的类型是帐户创建(管理员).
16.注册流程创建RBAC策略吗?
是的,根据NIST"RBAC策略是建立在功能之上或者在组织里用户可以实行的操作"(ANSI INCITS 359-2004).注册流程存在角色分配,角色分配就相当于RBAC policies,因为这些角色分配控制着用户的行为或者访问权限.
17.我可以自定义注册流程吗?
可以,对每种类型的注册流程,Oracle用户管理可以让客户根据业务需求创建自定义的注册流程.
18.我能定义自己的用户注册界面吗(UIs)?
可以,Oracle用户管理可以创建注册用户界面用来收集帐户和其他的附件信息.每一个注册流程都可以关联不同的一组用户注册界面.
19.什么是用户管理注册引擎(User Management Registration Engine)?
Oracle用户管理注册引擎控制所有的注册流程.当用户提交一个申请的时候,注册引擎利用Oracle工作流(Workflow)中定义业务逻辑来驱动注册流程.工作流进程控制:
触发注册事件关联(registration events)的业务事件(Business events)
为注册数据提供临时存储
身份认证流程
强制执行用户名策略
和Oracle Approval Management集成使用完成审批路径和规则
创建用户帐号
保留/释放帐户
分配恰当的角色
维护注册状态
触发预定义的通知工作流
20.用户管理触发工作流业务事件(Workflow Business Events)吗?怎么利用它呢?
是的,Oracle用户管理触发工作流业务事件,包含下列的时机:
当一个角色被申请
当一个帐户被申请
当一个帐户或者角色被批准
当一个帐户或者角色被拒绝
根据注册流程的所属,有专门的业务事件会把注册信息写到合适的空间(Schemas)中.
当这些业务事件被触发,包含在注册流程和注册内容中的信息都能够被获取,比如应用ID,角色代码和注册服务号等.客户可以订阅这些工作流业务事件(Workflow business Events)和按照自己的需要利用这些收集到的信息.更多关于订阅工作流业务事件的信息请参考Oracle Metalink Note:139745.1
21.什么是资格(Eligibility)
根据每个人的资格,既存用户可以通过Oracle User Management Access Request Tool(ART)请求附加的角色.ATR可以通过首选项(Preferences)菜单进行访问(笔记:叫做<访问请求> ).资格为访问请求流程(Additional Access Registration Process)定义了什么角色用户可以申请以及申请中定义了什么.比如说,员工有资格申请'销售代表'角色而客户就没有资格.尽管如此,每一个人都可以登陆iRecruitment去查找工作和职位.
22.帐户创建(管理员)流程对所有的管理员都是可用的吗?
不是,不是所用的管理员都可以使用的.尽管管理员可以从这些注册流程中获得便利,使得创建和维护账号变的流水化和简洁,但是每一个注册流程必须授权给一组合适的管理员.
23.在被批准之前,注册信息存放在哪里呢?
对于所有的注册流程,Oracle用户管理提供了一个机制以审批中(或者可以说是待定(pending))的状态存放注册数据直到请求被批准.这些数据对发送审批的工作流通知,审批管理事务以及那些最终写信息到目的表的业务逻辑都是可见的.Oracle用户管理通过Workflow Business Events架构中的事件对象(event Objects)来完成此工作.
24.我可以定制我自己的工作流通知吗?以及是否可以根据不同的角色定制进行定制呢?
可以,做为注册流程的一部分,客户可以在注册流程中定制自己的工作流通知以及挂接到不同的角色上面.每一个注册流程的工作流通知都可以不同.
工作流通知包括:
审批通知
审批确认通知
拒绝通知
身份验证通知
每当Oracle Approval Management规则引擎确定当前需要一个审批,Oracle用户管理就会触发注册流程相关联的通知工作流.审批者可以查看注册流程提交的信息,以及改变信息和按照需求添加一些额外的信息.所有的改变和添加的信息都会传送到用户管理中以供以后的流程使用.举例来说,一个请求获得iSP(Internet Supplier Portal)访问的请求,审批者可以为申请者提供站点和连接限制这些附加的信息.审批层次中,前面的审批者输入的信息包括注释,后面的审批者都可以查看.Oracle用户管理提供了简单的通知工作流,客户可以直接使用或者在此基础上做一些扩展按照需求.
25.当提交一个申请的时候都会显示的确认号(Confirmation number)是什么?它意味着什么?
当一个申请通过注册流程提交的时候,都会提供一个确认号.这个确认号代表了工作流中该请求使用的项目号(ITEM_KEY).使用该号码,申请者和管理员都可以跟踪该请求的状态以及查阅附加信息.
26.什么是Oracle审批管理(Oracle Approval Manager)已经它和Oracle User Management是如何联系的呢?
Oracle Approval Management 是一个高扩展性的审批规则引擎,客户可以利用它简单而高效的定义那些决定事务审批者的业务规则.用户可以设计简单或者复杂的规则.定义好的规则集中保存,可以有效的管理和实现业务流程的共享.规则引擎(Rules engine)的设计富有弹性,并且性能是该架构的基石.
更多关于Oracle Approval Management,请看看Oracle Approval Management的实施指南在Metalink的Note:227391.1.
27.可以自定义审批路径规则吗?
Oracle User Management是和Oracle Approval Management集成使用的,而Oracle Approval Management为所有的决定事务审批者的业务规则提供一个统一管理存储的平台.使用Oracle Approval Management,组织可以创建拥有优先级,条件和许多属性的复杂规则.
更多关于Oracle Approval Management,请看看Oracle Approval Management的实施指南在Metalink的Note:227391.1.
28.对于不同的国家,我们有不同的站点(web sites),可以按照帐户源流转审批请求吗?
User Management提供支持可以根据当前的访问是从那一个中间层(mid-tier)的登陆页面连接过来的而显示不同的注册连接(registration links).而该注册链接(Registration Link)可以包含附加的参数,一般来说,这些参数在设计的时候是未知的,比如国家代码.这些附加的参数可以在稍候的注册流程中使用.使用国家代码作为例子,一个注册流程可以流转审批请求到合适的审批者哪里,所有来自挪威的帐户申请都会被流转到一个挪威人账号审批者那里去.
请参考#31问题,获得关于在登陆页面中注册连接如何包含额外的参数的更多信息.
29.什么是用户名策略(User Name Policy)?
Oracle User Management提供支持,可以基于客户的规则,定义一个策略用来生产用户名.这些规则被定义在一个Oracle工作流里.Oracle User Management: User Name Policy. 默认封装在Oracle User Management中的策略是使用电子邮件做为该用户的用户名.用户名策略是一个可以很容易客户化的同步工作流进程.你可以更改工作流进程,使它可以根据注册流程中获取的信息或者存储在EBS里面的信息来生成符合要求的用户名.
30."忘记密码(Forgot Password)"功能是如何工作的?
Oracle User Management包含一个"忘记密码(Forgot Password)"的特性,本地用户(Local User)可以使用该特性重置自己的密码.这里的本地用户指的是那些密码没有在Oracle Internet Directory LDAP server里管理的用户.该特性需要身份验证,该帐户的拥有者必须通过邮件来确认密码更改.
该特性是通过Oracle Workflow来实现的,Oracle User Management: Password.客户可以客户化这个做为重置密码的一部分发送给用户的工作流信息.
31.登陆页面上的各种特性如何使用?
在Oracle Application的登录页面有许多可选的属性,这些属性是:
用户名提示(Username Hint)
密码提示(Password Hint)
取消按钮(Cancel Button)
忘记密码连接(Forgot Password Link)
注册连接(Register Here Link)
语言图片(Language Images)
萨班斯文字(Sarbanes Oxley Text)
这些属性都是通过一个配置文件(Profile file)来控制:"Local Login Mask" (FND_SSO_LOCAL_LOGIN_MASK).
为了在登录页面上显示一个或者多个这样的可选特性,只需用把所有要显示的属性的值加起来赋给该配置文件就可以.
下面的列表是每一个属性对应的具体值:
用户名提示(Username Hint)=01
密码提示(Password Hint)=02
取消按钮(Cancel Button)=04
忘记密码连接(Forgot Password Link)=08
注册连接(Register Here Link)=16
语言图片(Language Images)=32
萨班斯文字(Sarbanes Oxley Text)=64
如果一个客户想在登录页面显示"密码提示"和"忘记密码"属性,那么配置文件的值就是10(02+08).如果只显示语言图片,那么该配置文件的值就是32.在EBS中,32是默认值.
Oracle User Management可以根据不同的中间层访问显示不同的注册连接,客户可以设置服务器层的配置文件 "UMX: Register Here Link: Default Registration Process" (UMX_REGISTER_HERE_REG_SRV)去设置不同的注册连接.
注册连接也可以包含设计时不能确定的参数.这些参数可以在注册流程的任何阶段使用.举例来说,去流转审批请求(参看问题28).客户可以设置服务器层配置文件"UMX: Register Here Link: Default Registration Parameters" (UMX_REGISTER_HERE_REGPARAMS) 来达到此目的.
用户可以额外的指定一些参数来控制注册用户界面的渲染,比如什么菜单在注册流程里面显示.该参数是"UMX: Register Here Link: Default Html Parameters" (UMX_REGISTER_HERE_HTMLPARAMS)
32.实施Oracle User Management需要Oracle人力资源模块吗?
不需要,实施Oracle User Management不需要Oracle Human Resources.
33.升级到Oracle User Management 11.5.10会有什么变化?
升级到11.5.10,所有的Oracle User Management的新特性都会做为可选特性以供使用.客户可以根据需要选择使用其中一部分或者所有的特性.
如果你不想利用角色功能,你还是可以利用许多Oracle User Management的关键特性.下面特性就是在11.5.10里你不必实施角色这个新功能就可以利用的Oracle User Management新特性.
通过用户管理界面管理用户
注册流程
委托管理
自助申请
审批
34.我的客户是战略实施计划(Strategic Implementation Program (SIP))的候选人(candidate )吗?
Oracle User Management真正寻找做为候选人做为实施战略计划的合作伙伴.这个计划努力保证一组关键战略客户顺利实施EBS产品.
理想的候选人应该满足如下条件:
准备在11.5.10中安装和实施Oracle User Management
有效的Oracle支持合同
咨询和客户团队参与
愿意参加一个实例和宣传活动
执行承诺(客户&Oracle)
其他附加的SIP需求 (see SIP)
请联系您的Oracle客户代表来获的此计划的详细信息.
35.那些Oracle应用(Application)利用Oracle User Management 和 RBAC在11.5.10中?
Oracle User Management从版本11.5.10中引进.Oracle Application现在正在逐渐的利用Oracle User Management特性,以及包含在其中的RBAC特性.将来的版本中,会越来越多的利用到这些特性.
Last Updated: November 24, 2004 9:33 AM
36.RBAC的术语和定义
http://cs.uccs.edu/~sgfr/docs/RoleBasedAccesscontrolmarch1104.ppt
Terms and Definitions
?Component – refers to one of the major blocks of RBAC features, core RBAC, hierarchical RBAC, Static Separation of Duty (SSD) relations, and Dynamic Separation of Duty (DSD) relations.
?Objects – object can be any system resource subject to access control, such as a file, printer, terminal, database record, etc.
?Operations - An operation is an executable image of a program, which upon invocation executes some function for the user.
?Permissions - Permission is an approval to perform an operation on one or more RBAC protected objects.
?Role - A role is a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role.
?User - A user is defined as a human being. Although the concept of a user can be extended to include machines, networks, or intelligent autonomous agents, the definition is limited to a person in this document for simplicity reasons.
37.RBAC
www.cse.fau.edu/~security/public/RBAC_present.ppt
Role-Based AC
?A user has access to an object based on the assigned role.
?Roles are defined based on job functions.
?Permissions are defined based on job authority and responsibilities within a job function.
?Operations on an object are invocated based on the permissions.
?The object is concerned with the user’s role and not the user.
38.Permission and privilege
There is a distinction made between the terms permission and privilege. A privilege is a named ability to perform certain actions, such as read, write, delete, etc. A permission is a triple consisting of (a) a party (user or group), (b) a privilege, and (c) an object. A permission record basically says that party X has privilege P on object O.
39.怎样为一个用户赋予User Management职责
参考Note:734280.1 UMX Error: 'There are no functions available for this responsibility' And/Or 'There are no valid navigations for this responsibility' when Accessing 'User Management' Responsibility.
To implement the solution, please execute the following steps:
1. Log into the applications as SYSADMIN User.
2. Choose User Management responsibility.
3. Navigate to Users web page.
4. Search and find the user you want to inherit the Security Administrator and Customer Administrator Roles.
5. Click on Update Icon.
6. Click on Assign Roles button.
7. Find and choose 'Security Administrator' Role.
8. Apply.
9. Repeat the Steps (6-8) for 'Customer Administrator' Role.
10. Log as the user who was assigned User Management Responsibility and facing the issue.
11. Retest the issue.
12. Migrate the solution as appropriate to other environments.
其他参考资料
Note:377702.1 How Does RBAC Work with HRMS Defined Security Profiles?
Note:290996.1 Oracle User Management Additional Documentation
Note:760616.1 How to Use E-Business Suite Role Based Access Control (RBAC) in Discoverer