Authorization is the process of verifying that the user has the authority to perform the requested operations on the server. For example, when a client accesses an enterprise bean method the server must verify that the user of the client has the authority to perform such an access. Authorization occurs after authentication (confirming the user's identity).
VisiSecure uses a role database (a file whose default name is roles.db) to associate user identities with roles. If a user is associated with at least one allowed role, the user may access the method. For more information, see “Configuring authorization using the rolemap file”.
The class RolePermission is defined to represent “role” as permission. The Authorization Services Provider in turn provides the implementation on the homogeneous collection of RolePermissions contained for an association between given privileges and a particular resource.
The Authorization Service is tightly connected with the concept of the Authorization domain—each domain has exactly one Authorization Services Provider implementation. The Authorization domain is the bridge between the VisiSecure system and the authorization service implementation. During the initialization of the ORB itself, the authorization domains defined by the property vbroker.security.authDomains are constructed, while the Authorization Services Provider implementation is instantiated during the construction of the Authorization domain itself.
role-name {
assertion1 [, assertion2, ... ]
...
[assertion-n]
...
}
role-name2 {
assertion3 [, assertion4, ... ]
...
[assertion-n]
...
}
assertion1 [, assertion2, ... ]
...
[assertion-n]
...
}
role-name2 {
assertion3 [, assertion4, ... ]
...
[assertion-n]
...
}
A role entry is made up of a role name and a list of rules within curly braces (“{}”). A role must be made up of one or more rules. Each rule is a single line containing a list of comma-separated assertions for proper access identifications. Similarly, each rule must contain one or more assertions.
Each line in the Role Entry is a rule. Rules are read top-to-bottom, and authorization proceeds until one or none succeeds. That is, each rule is read as though separated by an “OR” operator. Assertions are separated on the same line by a comma (“,”). Assertions are read left-to-right, and all assertions must succeed in order for the rule to succeed. That is, each assertions in a rule is read as though separated by an “AND” operator.
This defines two roles, ServerAdministrator and Customer along with a set of rules and attributes which define them.
Once the rolemap file is complete, it can be referenced using the property vbroker.security.domain.<authorization-domain>.rolemap_path.
You can modify the authorization rolemap files by editing the rolemap file using properties given in the example directory. You can specify rolenames and attributes and thus associate users with roles. A role must be made up of one or more rules. For more information on rules and role entries, refer to “Assertion syntax”.
For configuring the database to store users, credentials and attributes, refer to “Using the userdbadmin tool”.
|
attribute = value
|
equals: attribute must equal value for authorization rule to succeed.
|
|
|
attribute != value
|
not equal: attribute must not equal value for authorization rule to succeed.
|
A value can be any string, but the wildcard character, “*” has special uses. For example, the attribute/value pair GROUP=* matches for all GROUPs. The following role has two associated rules:
The role manager has two rules associated with it. In the first rule, anyone named Kitty is authorized for manager, regardless of Kitty's associated group at the time. The second rule authorizes anyone in the group SalesForce1, regardless of their common-name (CN).
You make a wildcard assertion by placing the wildcard character (“*”) in front of the assertion(s) in one of two ways. You may place the wildcard character in front of a single assertion, meaning that all possible security attributes are accepted but they must contain the single assertion. Or, you may place the wildcard character in front of a list of assertions separated by commas within parentheses. This means all possible security attributes are accepted but they must contain the assertions listed in the parentheses.
Each role provides limited extensibility to others. You may, as a part of a role entry, specify a role=existing-role-name assertion that can extend an earlier role. You can also use customized code as your authorization mechanism rather than Role DB syntax by using the Authorization Provider Interface.
You can refer to the rules from an existing role by using the rule-reference assertion—role=role-name. For example, let's say we have a group of marketers who are also sales supervisors that need to be authorized to the same code as Sales Supervisors. Building upon the SalesSupervisor code sample, we can create a new role entry as follows:
During the initialization of the ORB itself, the authorization domain is defined by the property vbroker.security.authDomains. Each Role DB file is associated with an authorization domain. An authorization domain is a security context that is used to separate role DBs and hence their authorization permissions. For more information on the authorization domain in the context of the basic security model, see “Basic security model” on page 7.
To accomplish these items, the properties described in the following sections must be set. For more information about these properties, see “Security Properties for Java” or “Security Properties for C++”.
The path of the Role DB file is associated with the authorization domain <domain-name>. Although this can be a relative path, Micro Focus recommends you make this path fully-qualified.
A Run-as Alias is a string identifying an authentication identity. It is defined in the vault and scoped within the VisiBroker ORB. This alias then represents a particular user. The identity is mapped to the alias using either the Context APIs or by defining it in the vault. The vault can contain a list of run-as aliases and the corresponding authenticating credentials for the identity to run-as. In both cases, the authenticating credentials (from the vault or wallet) are passed to the LoginModules, which authenticate those credentials and set them as fully authenticated identities corresponding to those credentials in the run-as map.
|
1
|
Set the property in the server.properties file. This property specifies the name of the run-as role. The value can either:
|
|
a
|
be use-caller-identity to have the caller principal itself as the principal identity for the run-as role, or
|
|
1
|
Create a ServerQopPolicy.
|
|
2
|
|
3
|
Implement an AccessPolicyManager interface, which takes the following form:
|
This interface returns the authorization domain from the domain() method and uses it to set the access manager in the ServerQopConfig object. The domain specifies the name of the authorization domain associated with the proper rolemap. You set the location and name of the rolemap by setting the property:
where <authorization-domain-name> is a tautology, and <rolemap-path> is a relative path to the rolemap file.
The getAccessPolicy() method takes an instance of the servant, the object identity, and the adapter identity and returns an implementation of the ObjectAccessPolicy interface.
|
1
|
Implement the ObjectAccessPolicy interface that returns the required roles and a run-as role for accessing a method of the object. There is no difference between J2EE and CORBA run-as roles in Micro Focus's implementation. The ObjectAccessPolicy interface takes the following form:
|
The getRequiredRoles() method takes a method name as its argument and returns a sequence of roles. The getRunAsRole() method returns a run-as role, if any, for accessing the method.
In the corbaauthz example in the <install_dir>\examples\vbroker\security folder, the authorization requirement for the BankManager object is that the clients should be a member of the "Manager" role and for the Account it is "Customer" or "Teller" role.
The rolemap file contains the authorization data from the Role DB file. Members of the roles Manager, Customer and Teller are described in the bank.rolemap file, a snippet of which is shown below:
Any authenticated user with username=Administrator is a member of the role ‘Manager’.
Any authenticated user with group=cceng is a member of both role ‘Customer’ and role ‘Teller’.
Look at the different properties files (server.properties, client.properties) and config files (server.config and client.config) in the <install_dir>\examples\vbroker\security/corbaauthz folder.
|
If this property is set to true, during initialization, this property tries to log on to all the realms listed by the property vbroker.security.login.realms.
|
|
|
Specifies the location of the RoleDB file that describes the roles used for authorization. This is scoped within the domain <domain_name> specified in vbroker.security.authDomains.
|
|
|
When set to none, Authentication is not required. During handshake, no certificate request will be sent to the peer. Regardless of whether the peer has certificates, a connection will be accepted. There will be no transport identity for the peer.
|
|
|
This gives a list of comma-separated realms to login to. This is used when login takes place, either through property vbroker.security.login (set to true) or API login.
|
|
|
Specifies the callback handler for login modules used for interacting with the user for credentials. You can specify one of the following or your own custom callback handler. For more information, see “VisiSecure for C++ APIs”.
CmdLineCallbackHandler has password echo on, while HostCallbackHandler has password echo off.
|
The properties allow you to customize the behavior of VisiSecure. Depending on whether your application is Java, C++, or both, you may have to set different properties with different types of values. See “Security Properties for C++” and “Security Properties for Java” for all the properties you can set in this file.
To set up authorization for CORBA objects by using a vault, modify the following files in the corbaauthz example in the <install_dir>\examples\vbroker\security\example folder:
|
•
|
In the java server properties file, add the following properties:
In the Bank.idl file, make the following changes:
In the AccountImpl.java file, modify as shown in bold below.
In the server.java file, to write the AccountManager’s reference to a file for the client to access, add the following commands:
Add a new file ConverterServer.java. This file is the same server.java file that is in the corba authz example. Add the following that is given in bold:
|
7
|
|
9
|
Enter username: jeeves
|
|
10
|
Enter password: jeeves
|
|
11
|
|
2
|
When prompted, enter borland/borland.
|
|
8
|
When prompted, login as borland/borland.
|
|
9
|
There are three things that together specify jeeves@myrealm:
|
1
|
|
2
|
Setting the vbroker.security.domain.<domain-name>.runas.<role-name> property effectively maps an alias to a bean's run-as role. Upon successful authorization, but before method invocation, the container checks the Run-as role specified in the EJB's deployment descriptor for the called method. If a run-as role exists, the container checks to see if there is an alias as well. If there is, when the bean makes an outgoing invocation it switches to the identity for that alias.
Similar to the vault are other properties which only belong to the orb.properties file. These include secure listener ports, thread monitoring, and so forth.
In addition to ensuring the confidentiality and integrity of transmitted messages, you need to communicate caller identity and authentication information between clients and servers. This is called delegation. The caller identity also needs to be maintained in the presence of multiple tiers in an invocation path. This is because a single call to a mid-tier system may result in further calls being invoked on other systems which must be executed based on the privileges attributed to the original caller.
In a distributed environment, it is common for a mid-tier server to make identity assertions and act on behalf of the caller. The end-tier server must make decision on whether the assertion is trusted or not. When propagating context, the client transfers the following information:
|
•
|
Authentication token—client's identity and authentication credentials.
|
|
•
|
Identity token—any identity assertion made by this client.
|
|
•
|
Authorization elements—privilege information that a client may push about the caller and/or itself.
|
Identity assertion occurs when several servers with secure components are involved in a client request. At times, it is necessary for a server to act on behalf of its clients—when a client request is passed from one server to another. This is typical in the case where a client calls a mid-tier server, and the server further needs to call an end-tier server to perform a part of the service requested by the client. At such times, the mid-tier server typically needs to act on behalf of the client. In other words, it needs to let the end-tier server know that while it (the mid-tier server) is communicating with the end-tier server, access control decisions must be based on the original caller's privileges and not its privileges.
Impersonation is the form of identity assertion where there is no restriction on what resources the mid-tier server can access on the end-tier server. The mid-tier server can perform any task on behalf of the client.
The inverse of impersonation, delegation is the form of identity assertion where the client explicitly delegates certain privileges to the server. In this case, the server is allowed to perform only certain actions as dictated by the client. VisiSecure performs only simple delegation.
The identity assertion example in the \\VisiBroker\examples\vbroker\security\assertion example folder illustrates the use of identity assertion APIs which can be used to explicitly assert an identity as caller.
Members of the role Asserter are described in the bank.rolemap as follows:
This means that any authenticated user that belongs to group cceng must be a member of role Asserter.
Members of the role Manager are described in the bank.rolemap as follows:
(start Server -DORBpropStorage=cpp_server.properties on Windows)
The exception CORBA::NO_PERMISSION is thrown because only the asserted identity is authorized to make the invocation under the server configuration.
|
If set to true, at initialization time this property tries to log on to all realms listed by property vbroker.security.login.realms.
|
|
|
none—Authentication is not required. During handshake, no certificate request will be sent to the peer. Regardless of whether the peer has certificates, a connection will be accepted. There will be no transport identity for the peer.
|
|
|
This property is used to specify a list of trusted roles (specify with the format <role>@<authorization_domain>). <n> is uniquely identified for each trust assertion rule as a list of digits.
For example, setting vbroker.security.assertions.trust.1=ServerAdmin@default means this process trusts any assertion made by the ServerAdmin role in the default authorization domain.
|
|
|
Specifies the location of the RoleDB file that describes the roles used for authorization. This is scoped within the domain <domain_name> specified in vbroker.security.authDomains.
|
|
If set to true, at initialization-time this property tries to login to all the realms listed by property vbroker.security.login.realms.
|
|
|
Note: To use secure transport only, the secureTransport property must also be set to true.
|
|
|
none—Authentication is not required. During handshake, no certificate request will be sent to the peer. Regardless of whether the peer has certificates, a connection will be accepted. There will be no transport identity for the peer.
|
When a remote peer (server or process) makes identity assertions while acting on behalf of the callers, the end-tier server needs to trust the peer to make such assertions. The Service Provider Interface (SPI) allows you to plug in a Trust Services Provider to determine whether the assertion is allowed (trusted) for a given caller and a given set of privileges for the asserter. Specifically, you use the TrustProvider class to implement trust rules that determine whether the server will accept identity assertions from a given asserting subject. For more information, see sec-api-doc in the Help system, and the “Security SPI for C++”.
Backward trust is provided “out of the box”, and is the form of trust where the server has rules to decide who it trusts to perform assertions. With backward trust, the client has no say whether the mid-tier server has the privilege to act on its behalf.
Forward trust is similar to delegation in that the client explicitly provides certain mid-tier servers the privilege to act on its behalf.
At times, a server needs to access a privileged resource to perform a service for a client. However, the client itself may not have access to that privileged resource. Typically, in the context of an invocation, access to all resources are evaluated based on the original caller's identity. Therefore, it would not be possible to allow this scenario, as the original caller does not have access to such privileged resource. To support this scenario, the application may choose to assume an identity different from that of the caller, temporarily while performing that service. Usually, this identity is described as a logical role, as the application effectively needs to assume an identity that has access to all resources that require the user to be in that role.