I will not do a big introduction on WebORB security because I mainly want to show the security with some examples. It would however not be bad to read the following two things at http://www.themidnightcoders.com/doc30/ :

• Flex Integration –> Flex Remoting –> Security
• Server Infrastructure –> Security

Beside that read the comments in the Security section in the weborb.config file.

In my example I’ll work with the closed system.

From WebORB:

WebORB default authorization handler implements a powerful system for granting or denying access to the user classes, XML Web Services, CFCs or any other supported service type. The system supports 2 modes of operation: Open and Closed mode. The ‘Open System’ mode exposes all application classes and services to the rich client applications. Access can be restricted to individual methods, classes or packages/namespaces by creating specific access constraints. This mode is useful for development when infrastructure security has lower priority. The ‘Closed System’ mode is the opposite of the open mode. When running in the ‘Closed System’ mode, WebORB restricts access to all service types available in the application – all classes, xml services, EJBs and CFCs. Access to the individual methods, classes, packages/namespace can be granted by applying security access constraints.

The closed system is more secure and easier to manage, so I’ll work with that.

On the servers side I have one Class that needs security:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace Authentication
{
    public class TestService
    {
        /**
         * No access constraints should be defined for this method. In a closed system,
         * this means that no one should have access to this method.
         */ 
        public void Ping() { }
 
        /**
         * Access should be granted to all IP adresses.
         */ 
        public void AllIpPing() { }
 
        /**
         * Access should be granted only to Admin roles.
         */
        public void AdminPing() { }
 
        /**
         * Access should be granted only to User roles.
         */
        public void UserPing() { }
 
        /**
         * Access should be granted to users having both
         * Admin and User role.
         */ 
        public void AdminAndUserPing() { }
 
        /**
         * Access should be granted to users having 
         * Admin or User role.
         */ 
        public void AdminOrUserPing() { }
    }
}

Default WebORB Authentication/Authorization

First we’ll check the default Authentication/Authorization from WebORB. In the weborb.config check the section on Security:

1
2
3
4
5
6
7
8
9

<security>
      <deploymentMode>closed</deploymentMode>
      <authenticationHandler>Weborb.Security.WebORBAuthenticationHandler</authenticationHandler>
      <!--authenticationHandler>Johlero.Security.Handler.AuthenticationHandler</authenticationHandler-->
      <authorizationHandler>Weborb.Security.WebORBAuthorizationHandler</authorizationHandler>
      <!--authorizationHandler>Johlero.Security.Handler.AuthorizationHandler</authorizationHandlers-->
      <rolesProvider>Weborb.Security.WebORBRolesProvider</rolesProvider>
      <!--rolesProvider>Johlero.Security.Provider.RolesProvider</rolesProvider-->
</security>

Ok, closed system is set. Now we need to define the users. This is done at the end of the Security section in the weborb.config and should be set like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<acl>
      <user>
        <name>admin</name>
        <password>adminpass</password>
        <role>admin</role>
      </user>
      <user>
        <name>user</name>
        <password>userpass</password>
        <role>user</role>
      </user>
      <user>
        <name>adminuser</name>
        <password>adminuserpass</password>
        <role>user</role>
        <role>admin</role>
      </user>
</acl>

We have defined three users each with their password and the roles they are given. The adminuser is given two roles, user and admin. This will become clear later on in the Flex Part.

Now we need to set the constraints. At this point, no function in the TestService Class is accessible because of the Closed system.

First we’ll create some access constraints. You’ll see that some constraints are allready defined. We’ll use also one of those predefined constraints:

1
2
3
4
5
6
7
8
9
10
11
12
13

<access-constraint action="grant">
          <name>Constraint.Grant.UserRole</name>
          <role>user</role>
        </access-constraint>
        <access-constraint action="grant">
          <name>Constraint.Grant.AdminRole</name>
          <role>admin</role>
        </access-constraint>
        <access-constraint action="grant">
          <name>Constraint.Grant.AdminAndUserRole</name>
          <role>admin</role>
          <role>user</role>
</access-constraint>

First constraint grants access to the User role. The name is just a name that will be used further on in the secure-resource tags.
Second constraint grants access to the Admin role.
Third constraint grants access to users having both Admin AND User role. Be aware, this access-contraint does not say: give access to users having the Admin OR User role.
Besides giving access to a certain role it’s also possible to give access to IP adresses, IP ranges and hostnames. (See comments in weborb.config).

We will also use a IP access contraint:

1
2
3
4

<access-constraint action="grant">
          <name>everyone</name>
          <IP>*.*.*.*</IP>
</access-constraint>

Ok, so these access-constraints are like predefined security configurations that can now be used to secure resources. In the secure-resources tag in weborb.config add these lines:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<secure-resource>
          <resource>Authentication.TestService.UserPing</resource>
          <constraint-name>Constraint.Grant.User</constraint-name>
        </secure-resource>
        <secure-resource>
          <resource>Authentication.TestService.AdminPing</resource>
          <constraint-name>Constraint.Grant.Admin</constraint-name>
        </secure-resource>
        <secure-resource>
          <resource>Authentication.TestService.AdminAndUserPing</resource>
          <constraint-name>Constraint.Grant.AdminAndUser</constraint-name>
        </secure-resource>
        <secure-resource>
          <resource>Authentication.TestService.AdminOrUserPing</resource>
          <constraint-name>Constraint.Grant.Admin</constraint-name>
        </secure-resource>
        <secure-resource>
          <resource>Authentication.TestService.AdminOrUserPing</resource>
          <constraint-name>Constraint.Grant.User</constraint-name>
        </secure-resource>
        <secure-resource> 
          <resource>Authentication.TestService.Ping</resource>
          <constraint-name>everyone</constraint-name>
</secure-resource>

First secure-resource secures the Authentication.TestService.UserPing function with the Constraint.Grant.User constraint. This means that access to the UserPing function is granted to users that have the user role. So when along the Flex side user credentials are set (see ACL), access will be granted. Because of the closed system, ONLY user roles will have access.

Second secure-resource is analog to previous secure-resource, but now for Admin.

Third secure-resource secures the AdminAndUserPing with the AdminAndUser constraint. Here only access will be given to users having both user and admin role!

To give access to a Function for user having user OR admin role, you need to define two secure resources (fourth and fifth secure-resource).

The last secure-resource secures the Ping function with the everyone constraint. So everyone will have access to this resource.

In next post will show you how you can configure certain things with the Weborb Console (weborbconsole.html).