Oware Security Service
Introducing Oware Security
Security Design Basics
Users Login Security
Object-Level Security (OLS)
Inheriting Rule Permissions
Introducing Oware Security
This chapter describes how to implement Oware’s security. This version of Oware offers encrypted client/server communication, authentication, authorization and class-level security. Features in this version include the following:
• UserMonitor lets you view logged in users and terminate their applications remotely. You can monitor users on client applications with Oware, and find out what Mediation Agents, Application Servers, and Unlatches various clients run.
• ApplicationSecurityPolicy lets you modify values for a predefined set of policies related to login, users status and password constraints.
• User Management forms let an Admin disable, reset password, unlock user.
• Oware emits several security events: Logon, logOff, password change, locked out user, reset user, policy value changes.
• Selected data elements (user names, passwords, and so on) are encrypted used in the 3DES algorithm. Passwords are additionally encrypted using SHA-1. For these elements, data is encrypted both over the wire and when persisted.
Oware provides security you can implement for applications you create with it, and for client / server communication, as well as logins for the Oware Management Center (OMC), and the Oware Creation Center (OCC). Some details of Oware’s security features include the following:
Authentication --You can authenticate application clients to the server at login. A user may be authenticated based on a user name / password combination, a group membership, an X.509 certificate, or on a role (see User Roles). You can assign a unique set of permissions to each one of these authentication identities, and a user can have multiple identities. This is important for authorization, discussed below.
You can set Roles and assign them to users. Roles determine which application package users can manage.
Authorization -- Rules can use users’ identities to authorize their actions. For example, a Financial Analyst might be able to read/query the details of an invoice, but not update the invoice record. Initially, Oware supports control for the following actions: Read, Write, Execute, Browse, Add, Delete, Rename, Compare. See Authorization in Oware for details.
Class (Object) Level Security -- Administrators can specify what actions users can perform on objects themselves. While Oware's authentication lets developers attach permissions to rules based on the user, its security determines create, read, update and delete permissions at the class level.
Oware does not provide a default feature to restrict access at the attribute level. You could restrict such access by writing a rule that reads a user's profile and then filters access based on that information. By default, attribute-level permissions are unavailable throughout Oware to prevent a significant performance penalty from automatically filtering on every attribute every time a user accesses a class. Recommended best practice for Oware developers is to implement attribute-level security at the application level only on those attributes deemed critical. See Object-Level Security (OLS) for more.