Development and Implementation

In this development and improvement section, the information gained from the analysis section will be used. The coding is done in Perl Object Oriented Programming language to be compatible with the TWiki code and is written on Linux editor ”gedit” and eclipse integrated development environment (IDE) with EPIC¹ plugin.

1Eclipse Perl Integration

6.2.3.1 Module Development

First, a new empty module with the name ADFSUserMapping.pm is created.

This module is stored in the TWiki directory /twiki/lib/TWiki/Users/ on Apache’s web server (or IIS when using Microsoft).

Please find the complete module listing in Appendix A. For readability rea-sons, only the important code pieces will get shown in the listing 6.1.

1 #/ t w i k i / l i b /TWiki/ U s e r s /ADFSUserMapping . pm

17

22 return 0 unless defined $cUID ; 23

24 foreach my $ i d e n t ( s p l i t ( / \ , / , $ u s e r l i s t ) ) { # s p l i t w i t h o u t s p a c e / [ \ , \ s ]+/

25

26 $ a d f s g r o u p s = $ENV{HTTP ADFS GROUP} ;

27 next unless $ENV{HTTP ADFS GROUP} ;

28 $names2 = $TWiki : : U s e r s : : TWikiUserMapping : :

40 next unless $names ;

The above shown listing is the modified isInList function. By defining the whole path (TWiki::Users::isInList) as subroutine name, the new routine overrides the old one in Users.pm.

TWiki::Users::TWikiUserMapping is the base class for this module and in-herits all its attributes. The first part of the subroutine is a DENY check.

It reads out the settings from redirectView() and returns true value ($url ) or false value (0 ). The built-in function redirectCgiQuery is a program to change the URL, here from view to viewauth (see section 6.2.2.2).

The next part is the main isInList comparator. It gets the values from

$userlist (TWiki Topic setting) and splits the names in single entries into

$ident. The ADFS values can be imported From Apache’s environment vari-ables, for example with the command HTTP_ADFS_GROUPS.

$names2 is a variable coming from _expandUserList function to be able to work with settings in TWikiGroups (These settings are encapsulated and must

first be expanded).

After all the important values have been uploaded, the comparison can take place. This is a regular expression with pattern matching. If the ADFS group’s settings matches the TWiki Topic settings, a true (1 ) will get returned to checkAccessPermission function.

$adfs groups list $ident True?

IT-DEP CERN Users No

Austrians at CERN CERN Users No

CERN Users CERN Users yes

Table 6.2: Comparing Table

The same happens with the next comparison, the check against TWikiGroup settings. If all fail, a Perl false 0 value is returned to the requesting function.

6.2.3.2 DENY View Problem

The implementation shown above works well for ALLOW view settings in Topics and Webs. When a DENY command is set, no change from View to Viewauth appears. This is because DENY is stricter than ALLOW. For exam-ple, a Web or Topic owner can exclude TWiki Guests from viewing by defining a DENY command for them. For a DENY, no further action, such as forc-ing to Viewauth, has to be done. The denied person just receives an ”Oops webpage” as a result and gets redirected to the last public page s/he came from.

To use DENY settings for SSO E-groups, an additional step is relevant to bypass this problem. In the following development (listing 6.2), an artificial Viewauth force gets implemented.

1 sub r e d i r e c t V i e w {

Listing 6.2: ADFSUserMapping Development DENY View Solution

Listing 6.2 shows a new subroutine in ADFSUserMapping.pm module.

This subroutine faces the problems with DENY settings. In the first part, values from checkAccessPermission get imported. These variables contain the TWiki Topic settings. If the word DENY appears, the current URL will get replaced with the authentication version viewauth and returned to isInList subroutine. If no DENY is in the setting text, a false value will get returned and no URL replacement occurs.

6.2.3.3 Other Changes

Next to the module development, this enhancement affects other parts of the source code. To get a successful improvement, additional changes have to be done.

The new mapping module must being activated by changing the system con-figuration settings in TWiki/lib/LocalSite.cfg. This setting is configured to TWiki’s standard UserMapper:

$TWiki::cfg{UserMappingManager} = ’TWiki::Users::TWikiUserMapping’;

To guide the compiler to the new mapper, the path after the equal sign has to be modified:

$TWiki::cfg{UserMappingManager} = ’TWiki::Users::ADFSUserMapping’;

According to the DENY view problem, checkAccessPermission in Access.pm and _expandUserList in TWikiUserMapping.pm needs to be altered in or-der to read out variables at runtime. (see listing 6.2 DENY View Prob-lem: variable $denyTextTopic, $denyTextWeb). Please find the modified checkAccessPermission / _expandUserList subroutines in Appendix B.1

After these changes, ADFSUserMapping has its full functionality and is ready for use. The next chapter handles the testing phase. It is needed to find bugs within the code and to check if the module is working for all possible situations.

6.3 Testing

As stated in section 5.1 of this thesis, the last stage in SDLC is testing. After discussing development and implementation in the last sections, the coming paragraphs point out tests done for the module ADFSUserMapping after which the results of this testing are presented. In order to not to interfere with the production system, all tests are first planned and done on an identical test-server and the module is only transferred into production if all possible problems are fixed. After the successful installation of the module on the test-server, a testing plan is made to cover all possible positive and negative effects on the system. The next section describes the testing plan developed.