- Securing Operations

Securing Operations

[PRO] WOW has a powerful security feature that can be set from within each individual operation. The security measures within the operations are used to allow only certain users with a specific security level to view operations. Every user (anonymous or otherwise) by default has a security level of zero, unless otherwise specified. WOW uses a simple number scheme to control which users can view certain operations within a specific WOW Application. When an operation is set to a security level of 0, all users will have access to that operation. When an operation is set to another security level, only users with security level equal to or higher than the operation’s security level will have access to that operation. An operation’s security level can be set in that operation’s detail screen. The Security options are found under the Administration section as show in the screen shot below:

Security Settings

Security Type: The Security type is where you set the initial security mode for the operation. Security Type has two available settings. Level Security is the most powerful of the settings. It uses a numbering scheme to specify how restricted an operation should be. Operation Security specifies criteria a user must have to be allowed access to the operation.

Level Security – This is the most powerful of the security settings that are available within WOW. When the Security Type is set to Level Security, WOW will use the Security Level field to limit access to the operation. Only users with a Security Level equal to or greater than the operation’s Security Level can access the operation.

Operation Security – Allows a very versatile way to secure operations. When the Security Type is set to Operation Security, WOW will use the User Authorization Operation selected in the Execute Authority Operation field to limit access to the operation. Only users matching the specified criteria will have access to view or run the operation. (i.e. have one of a set of usernames, or belong to a user group, etc.) If no operation is selected, then all users will have access to the operation.

See section Securing Fields and Operations with User Authorization Operations for more details.

TODO: Promote as recommended approach and provide example and promote as EE TIP. [PHOLM]

Unsecured – An unsecured Operation has no security measures. This means that anyone who uses WOW can use that Operation. This is similar to a security level of 0 when using the Level Security Feature. An unsecured SQL Operation can be viewed by all users of the application. (An unsecured operation is different than an unsecured application. The application may optionally require users to sign in before using the application, or it may allow access to “anonymous” users.)

Secured Operation Example:

This example is can also be found under the “Level Based Security” application provided with the sample applications. This example assumes an application has already been created and has its sign on type set to SQL Operation.

First, we need to create an Authentication Operation to use for authenticating users. Follow steps provided previous in the chapter on how to create an authentication operation. For this example, the Authentication’s Operation SQL will be:

SELECT seclevel FROM planetj.user WHERE email = ? AND password = ?

This sign on Operation will validate the email and password given by a user and if valid, store that user’s urseclevel Field’s value as a user property. Listed below are some of the Fields and values that can be found in the planetj.user table. There are actually more columns than these, but we only need three for this example.

You’ll notice that Joe Public has a security level of 0 and Peter Poweruser has a security level of 6. This value will be stored as a user property when each of them sign in to the application. Next, we create another operation, this time just a regular SQL Operation. Its operation code can be set to:

SELECT * FROM planetj.emp

This operation should also be secured. To do this, set the operation’s security type to Level Security, along with a level of 2.

Now when the two users sign on, neither will be able to see this operation. Peter Poweruser has a security level of 6, so why can’t he see it? There’s one more step that needs to be done. The SecLevel Field is being stored as a user property, but in order for the security feature utilizing Level Based Security to pick it up, the SecLevel’s FieldDescriptor needs to have its usage id set to -160. This usage id value denotes a Security Level Field.

Now when Peter Poweruser signs in, he will be allowed to see the Operation for view employees, where as Joe Public still cannot see it because his security level field value is not greater than or equal to the Operation’s security level.

Optional Sign On

In some scenarios, you may have an application with certain operations that anyone can use and other operations to which only certain users have access. In this case, you may want to let users access your application without signing on, as long as they limit themselves to the operations available to everyone. To allow users to access the application without signing on, but still allow them to sign on if they want to, check the “Optional Sign On” checkbox in the application details screen:

When a user starts an application whose sign on is optional, they are presented with a screen similar to this one (the operations will vary depending on the application):

There is a sign on area in the top left of the screen which the user can use if he or she wants to sign on. If the user does not sign on, then that user has a security level of 0, and only has access to operations which also have a security level of 0. Once signed on, the user has a security level determined by the userid used to sign on, and will have access to all operations with a security level equal to or less than the user’s security level.

NOTE: Optional Sign On is only supported when the sign on type is SQL Operation.