Authentication:
Who you are
Identifies the user attempting to log on.
Requires credentials (a user name and password).
Uses an authentication provider (LDAP directory service).
Creates a security token (a data structure that typically persists until the user logs out).
Uses JAAS and WS-Security standards.
Authentication - Authentication is the act of verifying a user identity based on credentials that the user presents. Authentication of individuals, or ideally of the roles that an individual has, through the external authentication mechanism is key to the security features in IBM FileNet Content Manager. The two standards at the core of the authentication process in FileNet Content Manager are the Java Authentication and Authorization Service (JAAS) standard and the Web Services Security standard. The JAAS standard forms the framework for security interoperability in the Java EE world, while the Web Services Security standard forms the framework for security interoperability in the heterogeneous world of clients and servers that communicate through web services interfaces.
Authentication provider - An authentication provider is a supported LDAP-compliant directory service that provides authentication for the FileNet P8 Domain. The authentication provider is identified during FileNet P8 installation. Supported directory service providers include IBM Tivoli Directory Server, CA Directory, Novell eDirectory, Sun Java Directory Server, Oracle Directory Server, and Microsoft Active Directory.
Token - The security token contains the user name, the user security ID, the group memberships of the user, and the group security IDs.
Authorization:
What you can do
Determines what the user can do (view, delete, modify, and so on).
Requires prior authentication.
Content Engine authorization is object based.
When a security principal that has already been authenticated attempts to access FileNet P8 objects, Content Engine or Process Engine will attempt to retrieve that principal's user and group memberships from the directory service provider. If successful, the user or group will be authorized to carry out actions described by the access rights placed on the object.
User roles
Different user roles are responsible for securing different types of objects. For example, administrators, solution builders, authors, and users might have different access rights to the same objects.
Even administrators with access to Enterprise Manager can have different levels of access to objects. For example, one administrator might have permission to modify document classes, properties and templates that another administrator has no access to.
Independent and dependent security
Most objects have Access control Lists (ACLs) that can be independently set. These objects are called independently securable.
Dependently securable objects are dependent on their parent object for their access rights. They are secured through the parent object.
Examples of dependently securable objects:
Content elements, which have the same security as the associated document object
A property assigned to a securable object, which has the same security as that object
The individual choices in a choice list, which have the same security as the object that the choice list is assigned to
A lifecycle state in a lifecycle policy
Security involves more than simply securing documents and folders. The security of the system design determines which objects are securable by which users. For example, administrators might be responsible for securing the domain root and the object stores. Application builders might be responsible for securing classes, instances like stored searches and entry templates, and property templates. Authors might be responsible for securing folders and documents depending on the design.
Who you are
Identifies the user attempting to log on.
Requires credentials (a user name and password).
Uses an authentication provider (LDAP directory service).
Creates a security token (a data structure that typically persists until the user logs out).
Uses JAAS and WS-Security standards.
Authentication - Authentication is the act of verifying a user identity based on credentials that the user presents. Authentication of individuals, or ideally of the roles that an individual has, through the external authentication mechanism is key to the security features in IBM FileNet Content Manager. The two standards at the core of the authentication process in FileNet Content Manager are the Java Authentication and Authorization Service (JAAS) standard and the Web Services Security standard. The JAAS standard forms the framework for security interoperability in the Java EE world, while the Web Services Security standard forms the framework for security interoperability in the heterogeneous world of clients and servers that communicate through web services interfaces.
Authentication provider - An authentication provider is a supported LDAP-compliant directory service that provides authentication for the FileNet P8 Domain. The authentication provider is identified during FileNet P8 installation. Supported directory service providers include IBM Tivoli Directory Server, CA Directory, Novell eDirectory, Sun Java Directory Server, Oracle Directory Server, and Microsoft Active Directory.
Token - The security token contains the user name, the user security ID, the group memberships of the user, and the group security IDs.
Authorization:
What you can do
Determines what the user can do (view, delete, modify, and so on).
Requires prior authentication.
Content Engine authorization is object based.
When a security principal that has already been authenticated attempts to access FileNet P8 objects, Content Engine or Process Engine will attempt to retrieve that principal's user and group memberships from the directory service provider. If successful, the user or group will be authorized to carry out actions described by the access rights placed on the object.
User roles
Different user roles are responsible for securing different types of objects. For example, administrators, solution builders, authors, and users might have different access rights to the same objects.
Even administrators with access to Enterprise Manager can have different levels of access to objects. For example, one administrator might have permission to modify document classes, properties and templates that another administrator has no access to.
Independent and dependent security
Most objects have Access control Lists (ACLs) that can be independently set. These objects are called independently securable.
Dependently securable objects are dependent on their parent object for their access rights. They are secured through the parent object.
Examples of dependently securable objects:
Content elements, which have the same security as the associated document object
A property assigned to a securable object, which has the same security as that object
The individual choices in a choice list, which have the same security as the object that the choice list is assigned to
A lifecycle state in a lifecycle policy
Security involves more than simply securing documents and folders. The security of the system design determines which objects are securable by which users. For example, administrators might be responsible for securing the domain root and the object stores. Application builders might be responsible for securing classes, instances like stored searches and entry templates, and property templates. Authors might be responsible for securing folders and documents depending on the design.
No comments:
Post a Comment