Planning Your Installation

The next step is to determine the business tasks associated with each role. Business tasks are broadly grouped here under the term “permissions”, each representing a distinct and separable conceptual area of job responsibility. Interviews with people working in each business unit will help you to determine the business tasks required for each role.

Roles may require one or many permissions, but each role should have at least one, and each permission should be associated with at least one role. A role with no permission is like a job without any responsibilities; a permission with no role is like a task assigned to no one.

The following table shows the permissions determined for each role in HealthCo:

This step correlates the resources available to users on the organization’s IT network with the permissions, or business tasks, assigned to each role. To complete this step, you need to perform a detailed analysis of the Web applications, their structures and their deployment. Consult with the Web architects and system administrators as required. Directory listings obtained using dir or ls commands can be helpful, as can J2EE XML descriptors for application servers.

If a test system running a copy of the production applications is available, you can install a preliminary instance of the DirX Access server and deploy resource explorers on the Web and application servers in the test system. The resource explorers will enumerate the resources in a tree view within the DirX Access Manager.

Note that some permissions might not have associated resources, if the job responsibility is performed without a dedicated network application. On the other hand, some resources may apply to more than one permission, in cases where different job responsibilities require access to the same application. However, each resource you identify in your analysis of the organization’s IT network must be assigned to a permission. Otherwise, that resource will be unprotected by DirX Access.

HealthCo has the following fictional resources that correspond to each of the permissions defined in the previous step.

When you define resources in DirX Access Manager, you can use wildcard strings to expand the scope of the resource. Wildcards are also supported by both the resource explorers and the PDP. For example, the Interventions permission above could have a single resource identified as http://health.com/HL7_I*.

In this step, you assign one or multiple roles to each user in the organization based on the job functions they perform.

Up to this point, you have been determining resource and security objects to form a stable basis for the security system. Organizational domains, job roles and job responsibilities are unlikely to change significantly moving forward, barring large-scale company reorganizations. However, user-to-role associations are far less stable, as users frequently come and go in the organization, and regularly change roles due to promotions.

The table below illustrates HealthCo’s user-to-role associations:

For the sake of simplicity, this example does not use groups. However, if your organization contains many users that can fulfill specific roles, you may choose to create groups and assign the roles to the groups instead of assigning the roles directly to the users themselves. This one-to-many relationship can further ease the on-going administration of the system.

The final step in planning your security model is to determine the authentication method or methods that must be used to identify users for each resource defined in your system. To set these authentication methods appropriately, consider the critical value of the resource.

Consider also the network or directory structure of your Web applications, as displayed by the resource tree view in DirX Access Manager. If you apply an authentication method to a given branch in your resource tree, all resources in subordinate branches will inherit that same method. You can, for example, set less secure authentication methods for the root of your resource tree, and stronger authentication methods for lower branches that contain confidential information.

The following authentication methods are available:

For details on these authentication methods, see the chapter “Administrative Tasks” -> “Managing Configuration Data” -> “Managing Authentication Methods”.

As an alternative to specifying the particular authentication method that must be used to access a resource, consider using assurance level conditions. You can assign a numeric assurance level to each authentication method, and require a given assurance level in order to access individual resources.

For example, if a resource is assigned an assurance level condition of 5, users can only access that resource if they have authenticated themselves using a method that has a configured assurance level of 5 or higher.

At this point, your hardware and software has already been deployed, and your security model has been constructed in conceptual terms. You must now feed your security model into DirX Access.

The main DirX Access administrator is required to begin the process by creating all roles, policies and users. All tasks are performed using the DirX Access Manager administrative interface, described in the chapter “Administrative Tasks.”

The steps for configuring a security model are as follows, listed with their corresponding sections in the chapter “Administrative Tasks” for reference:

DirX Access federation endpoints run in the DirX Access Services container and are responsible for dealing with other authentication and authorization systems by exchanging business roles and authentication tokens over a SAML or OAuth framework. DirX Access federation endpoints provide support for cross-domain single sign-on between your local applications and other applications on remote networks. It is possible to have multiple instances of DirX Access federation endpoints running in a single DirX Access Services container.

You must design your federation system in close collaboration with the administrators of your partner sites. There are three main issues to keep in mind when deploying DirX Access to create federations in your environment. You and your SAML partners must:

These details must be determined in advance for you to configure your federations.

The DirX Access federation endpoint is deployed within the DirX Access Services container.

The following diagram indicates a possible DirX Access federation deployment, in which the DirX Access system is the source site asserting users’ authentication when they visit a remote destination site. The remote destination site may use DirX Access or a third-party access management solution. Note that in actual deployments, DirX Access can act as the source site, the destination site, or both.

Although a DirX Access Services container with DirX Access federation endpoints can be located anywhere on the network, it is possible to locate it in a protected zone behind a firewall. You can locate Web proxy servers in a demilitarized zone (DMZ) on your extranet and allow access to your DirX Access federation endpoints through those proxies. You must set strict firewall rules to tighten security around the interactions required between your network components. These interactions are listed below: