This chapter includes the following sections:
Note:
Always create a backup of a domain before you load XACML documents into a security realm. If you make a typographical or other type of error in an attribute description, you can cause the XACML provider to evaluate your realm's roles and polices as indeterminate, which locks all users (including the administrative user) out of the domain. See Caution: Indeterminate Results Can Lock Out All Users.
The WebLogic Server XACML Authorization Provider and the WebLogic Server XACML Role Mapping Provider implement the XACML 2.0 Core Specification, available at http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf
.
Note the following prerequisites for using XACML documents to secure WebLogic resources:
To add XACML authorization policies to a security realm, the realm must use either the WebLogic Server XACML Authorization Provider or a third party authorization provider that implements the weblogic.management.security.authorization.PolicyStoreMBean
interface.
To add XACML role assignments to a security realm, the realm must use either the WebLogic Server XACML Role Mapping Provider or a third party authorization provider that implements the weblogic.management.security.authorization.PolicyStoreMBean
interface.
To secure a resource with a XACML authorization or role policy, you need the resource identifier (ID). Because WebLogic Server creates an immutable, unique ID when you deploy or create a resource, you must deploy the resource before creating a policy for it.
To secure an EJB or Web application, you must deploy using the Custom Roles or Custom Roles and Policies security model. You cannot use a XACML document to create roles and polices for an EJB or Web application that you have deployed using the Deployment Descriptor Only security model. See Comparison of Security Models for Web Applications and EJBs.
You can create a XACML document that describes roles and policies and then use the WebLogic Scripting Tool to add the policy or role to your security realm.
The main steps for this process are as follows:
The XACML specification requires that if the decision engine is unable to process a decision point, the engine returns a result of indeterminate. Depending on the combining algorithms that you use for a decision point and its associated decision points, an indeterminate result can propagate to the top of the decision and cause the provider to deny access to all requests.
For example, the following attribute specifies MustBePresent='true'
and contains a spelling mistake (ancester
instead of ancestor
). It will evaluate as indeterminate and will cause the security provider to deny access:
<ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancester" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
WebLogic Server organizes its resources into a hierarchy. If you use the WebLogic Server Administration Console or a Java EE deployment descriptor (instead of a XACML document) to secure WebLogic resources, policies that you create on resources that are higher in the hierarchy act as default policies for resources lower in the same hierarchy. Policies lower in a hierarchy always override policies higher in the hierarchy.
Your XACML document can encode this hierarchical protection scheme, though XACML's hierarchical model differs slightly from WebLogic Server. See Comparison of WebLogic Server and XACML Security Models.
WebLogic Server creates an immutable, unique identifier (ID) when you deploy or create a resource, and your XACML document must include a resource identifier that specifies the WebLogic Server ID.
To find the ID that WebLogic Server has assigned to a resource:
If you want to create role assignments and authorization policies, create two XACML documents: one that describes your roles and another that describes your policies. You load one of the documents into the Role Mapping provider's store and the other into the Authorization provider's store.
For information about using XACML to describe WebLogic Server resources, see Reference for XACML on WebLogic Server.
The syntax for describing role assignments in a XACML document is specified in the OASIS RBAC Profile specification, available at http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-rbac-profile1-spec-os.pdf
. (WebLogic Server supports only a subset of this specification.)
The syntax requires the following elements:
A Policy
parent element.
Under Policy
, a Target
element.
Under Target
, at least one Resource
element that contains the following ResourceMatch
elements:
(Optional) One ResourceMatch
element to identify the name of the role. If you do not include this ResourceMatch
element, then the role policy applies to all roles in the realm. The MatchId
attribute may specify function identifiers and, thus, wildcard role names. The DataType
attribute must specify the string
type.
(Optional) Another ResourceMatch
element to identify the WebLogic resource to which the role applies. If you do not include this ResourceMatch
element, the role applies to all WebLogic resources.
Under Target
, an Action
element that indicates that the policy applies to a role instead of some other type of resource.
Under Policy
, one or more Rule
elements that define which users, groups, or roles are in the role.
The XACML document in Example 7-1 specifies that a role named MyRole
role can be used with the SimpleSoapPort
Web Service. It also specifies that the webServiceGroup
group is in the role.
Note:
When specifying values in the <AttributeValue>
element, you must not include extraneous space characters. In particular:
Do not precede the first value with more than a single space character.
When specifying multiple values, do not separate each value by more than a single space character.
Make sure there are no space characters that follow the last value.
For example:
<AttributeValue datatype>value1, value2, value3</AttributeValue>
Example 7-1 XACML Policy for a Role
<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicyId="urn:bea:xacml:2.0:myRolePolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"> <Description>Grp(group1)</Description> <Target> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=<webservices>, application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple, webService=SimpleSoapPort</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/> </ResourceMatch> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">MyRole</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/> </ResourceMatch> </Resource> </Resources> <Actions> <Action> <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">urn:oasis:names:tc:xacml:2.0:actions:enableRole</AttributeValue> <ActionAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="http://www.w3.org/2001/XMLSchema#anyURI" MustBePresent="true"/> </ActionMatch> </Action> </Actions> </Target> <Rule RuleId="primary-rule" Effect="Permit"> <Condition> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">webServiceGroup</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:group" DataType="http://www.w3.org/2001/XMLSchema#string"/> </Apply> </Condition> </Rule> <Rule RuleId="deny-rule" Effect="Deny"/> </Policy>
The XACML document in Example 7-2 specifies that only the MyRole
role can access the SimpleSoapPort
Web Service.
Example 7-2 XACML Policy for a Web Service
<?xml version="1.0" encoding="UTF-8"?> <Policy xmlns="urn:oasis:names:tc:xacml:2.0:policy:schema:os" PolicyId="urn:bea:xacml:2.0:myPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"> <Description>Rol(MyRole)</Description> <Target> <Resources> <Resource> <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">type=<webservices>, application=webservicesJwsSimpleEar, contextPath=/jws_basic_simple, webService=SimpleSoapPort</AttributeValue> <ResourceAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/> </ResourceMatch> </Resource> </Resources> </Target> <Rule RuleId="primary-rule" Effect="Permit"> <Condition> <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-is-in"> <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">MyRole</AttributeValue> <SubjectAttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role" DataType="http://www.w3.org/2001/XMLSchema#string"/> </Apply> </Condition> </Rule> <Rule RuleId="deny-rule" Effect="Deny"/> </Policy>
The WebLogic Scripting Tool (WLST) is a command-line scripting interface that you can use to load your XACML document into a WebLogic security realm.
You can use WLST in interactive mode or script mode. You cannot use WLST in offline mode; the Authentication provider and Role Mapping provider can update their policy stores only when the Administration Server is running.
For information about using script mode, see Using the WebLogic Scripting Tool in Understanding the WebLogic Scripting Tool.
The following steps describe using the WLST interactive mode:
Start the WebLogic Server instance that contains the realm you want to configure.
Open a command prompt and set up the environment for running WLST.
One way to set up the environment is as follows:
Change to the root directory of the domain.
Invoke the setWLSenv
script (the Domain Configuration Wizard creates this script for you when you create the domain).
Change to the directory that contains your XACML document.
To start WLST and connect to a WebLogic Server instance that is listening at localhost:7001
, enter the following commands:
java weblogic.WLST
This command returns a WLST prompt.
connect('
username
','
password
','localhost:7001')
where username
and password
are credentials for an administrative user.
To load a XACML document into a Java String
object, enter the following commands:
xacmlFile = open('
myfile
','r')
where myfile
is the name of your XACML document.
xacmlDoc = xacmlFile.read()
(Optional) To verify that you have loaded your document into a String
, enter:
print(xacmlDoc)
The command prints the value of the xacmlDoc
variable to standard out.
To load role assignments into the WebLogic XACML Role Mapper, enter the following commands:
cd ('SecurityConfiguration/
mydomain
/Realms/
myrealm
/RoleMappers/XACMLRoleMapper')
where
mydomain
is the name of your WebLogic Server domain
myrealm
is the name of your security realm
cmo.addPolicy(xacmlDoc)
or cmo.addPolicySet(xacmlDoc)
, depending on whether your XACML document contains a Policy
or PolicySet
.
To load authorization policies into the WebLogic XACML Authorizer, repeat step 5 to load your XACML policies document, Then enter the following commands:
cd ('SecurityConfiguration/
mydomain
/Realms/
myrealm
/Authorizers/XACMLAuthorizer')
where
mydomain
is the name of your WebLogic Server domain
myrealm
is the name of your security realm
cmo.addPolicy(xacmlDoc)
or cmo.addPolicySet(xacmlDoc)
, depending on whether your XACML document contains a Policy
or PolicySet
.
To see a full list of operations that you can use to add, modify, or delete policies, see XACMLAuthorizerMBean
in MBean Reference for Oracle WebLogic Server.
The WebLogic Server Administration Console does not display roles and policies that you add from a XACML document.
Instead, to verify that your roles and policies were added to the realm, see Exporting Roles and Policies to XACML Documents.
A Managed Bean (MBean) is a standard for exposing management data and operations for a resource. Your application developers can greatly reduce the cost of operating and maintaining your applications by creating MBeans (custom MBeans) to monitor and manage your applications. See Developing Manageable Applications Using JMX for Oracle WebLogic Server.
If you register custom MBeans in a WebLogic Server MBean server, you can create a XACML document that defines who can access your MBeans. In addition to the prerequisites described in Prerequisites, note that your MBean's object name must include a Type=
value
key property.
The main steps for creating roles and policies for custom MBeans are:
When you register a custom MBean with a WebLogic MBean server, the WebLogic security service creates two resource IDs for each attribute in the MBean: one for the attribute's getter method and another for the setter. It creates one resource ID for each MBean operation.
The IDs use the following pattern:
type=<jmx>, operation=type-of-access, application=, mbeanType=type-name, target=attribute-or-operation
In the preceding pattern:
type-of-access
specifies the type of access that the policy secures. Use one of the following values:
get
Indicates that the policy controls who can read one or more MBean attributes.
set
Indicates that the policy controls who can write one or more MBean attributes.
invoke
Indicates that the policy controls who can invoke one or more MBean operations.
create
Indicates that the policy controls who can use the MBean-server's create
method to create an instance of an MBean.
unregister
Indicates that the policy controls who can use the MBean-server's unregister
method to unregister an instance of an MBean.
type-name
is the value of the MBean object name's Type
key property.
attribute-or-operation
is the name of an MBean attribute or operation.
For example, if you create an MBean that contains a single attribute named NewUserCount
and an operation named clearNewUserCount
, and if you register the MBean under the object name medrec:Name=AdminReportMBean,Type=CustomMBeanType
, then the security service creates the following resource IDs:
type=<jmx>, operation=get, application=, mbeanType=CustomMBeanType, target=NewUserCount type=<jmx>, operation=set, application=, mbeanType=CustomMBeanType, target=NewUserCount type=<jmx>, operation=clearNewUserCount, application=, mbeanType=CustomMBeanType,target=
To see a XACML representation of all roles and policies that are in your security realm, you can export the data from the Authorization and Role Mapping providers.
Note:
Do not attempt round-trip editing of roles and policies. That is, do not export roles and policies, modify the XACML documents, and then import the modified documents. Editing exported files might result in an unusable WebLogic Server configuration and is not supported.
For information on how to export security data, see Export data from a security provider in the Oracle WebLogic Server Administration Console Online Help.