Using the ISecurity Server Interface

Calling the Server Interface

The ISecurity interface is called by connecting to the SAS Metadata Server and obtaining a handle to the ISecurity server interface.
A SAS Java Metadata Interface client accesses the ISecurity server interface by importing the appropriate packages, instantiating an object factory, and connecting to the SAS Metadata Server with a handle to the interface that is appropriate for the task that it wants to perform.
The ISecurity server interface is provided in the sas.oma.omi.jar file in the SAS Platform VJR. A Java client accesses the ISecurity server interface by importing the appropriate com.sas.meta.SASOMI packages.
The ISecurity interface versions are designed so that existing SAS clients can continue to work unchanged.
  • To use SAS 9.1 methods only, import com.sas.meta.SASOMI.ISecurity and com.sas.meta.SASOMI.ISecurityPackage.
  • To use SAS 9.1 methods and methods introduced after that release, import com.sas.meta.SASOMI.ISecurity_1_1 and com.sas.meta.SASOMI.ISecurity_1_1Package.
The SAS Java Metadata Interface provides the MdFactory interface to instantiate an object factory for the SAS Metadata Server and the MdOMRConnection interface for connecting to the SAS Metadata Server. Use the MdOMRConnection interface's makeISecurityConnection method to connect to the server with the ISecurity server interface.

Identifying Resources to ISecurity Methods

Many ISecurity methods have a resource parameter. A resource is a metadata object that represents the entity on which authorization or another action is requested.
A resource is identified by a URN in one of two forms:
OMSOBJ:MetadataType/ObjectId 
REPOSID:_reposID
OMSOBJ indicates that the request is to the SAS namespace of the SAS Metadata Model. The SAS namespace contains metadata types that describe application elements. MetadataType is one of the SAS namespace metadata types. For a list of supported metadata types, see the SAS Metadata Model documentation. ObjectId is the requested object's 17–character metadata object identifier. The first eight characters of the object identifier are a repository identifier; the remaining eight characters are the unique object instance identifier.
REPOSID indicates the request is to the REPOS namespace of the SAS Metadata Model. The REPOS namespaces contains metadata types that describe a repository. The first eight characters of a repository ID are the SAS Repository Manager identifier A0000001, which is the same for all repositories. Therefore, you need specify only a repository's unique 8–character object instance identifier in _reposID.

Identifying Users

The SAS Metadata Server supports user identities of metadata type Person, IdentityGroup, and Role.
Most ISecurity methods accept a credential handle or use the user ID of the calling user to identify the identity for which to return an authorization or information. A credential handle is a token representing an identity's authorizations on the SAS Metadata Server . A handle is obtained with the GetCredentials method. For more information, see GetCredentials.
The following methods support additional ways to specify the identity for which to process a request:
  • The GetApplicationActionsAuthorizations method supports submission of the string ROLE_rolename to specify a Role. For more information, see GetApplicationActionsAuthorizations.
  • The GetIdentity method supports submission of the string LOGINID: userid to identity a Person or IdentityGroup. For more information, see GetIdentity.
  • The GetInfo method supports the submission of an identity resource identifier in the form IdentityType: Name, where IdentityType can be Person, IdentityGroup, or Role. For more information, see GetInfo.
Methods that create and manage internal user accounts use a different convention to identify a user. Internal user accounts are supported only for identities of metadata type Person. These accounts rely on the Person object's Name value to identify the account. Therefore, methods that create and operate on internal user accounts require you to identify the internal user by name. For more information, see the following: