Dieter Zeller Design and development of a user management ...genome.tugraz.at/Theses/Zeller2003.pdf · for molecular biology database systems Master ... Binding an access control

Dieter Zeller

Design and development

of a user management system

for molecular biology database systems

Master Thesis

Institute of Biomedical Engineering,

Graz University of Technology

A-8010 Graz, Austria

Head of Institute: Univ.-Prof. Dipl.-Ing Dr.techn. Gert Pfurtscheller

Supervisor: Univ.-Prof. Dipl.-Ing. Dr.techn. Zlatko Trajanoski

Advisor: Dipl.-Ing. Michael Maurer

Advisor: Dipl.-Ing. Robert Molidor

Graz, October 2003

Dieter Zeller

Entwurf und Entwicklung

eines Benutzerverwaltungssystems

fur molekular biologische Datenbanksysteme

Diplomarbeit

Institut fur Elektro- und biomedizinische Technik,

Technische Universitat Graz

A-8010 Graz

Vorstand: Univ.-Prof. Dipl.-Ing Dr.techn. Gert Pfurtscheller

Begutachter: Univ.-Prof. Dipl.-Ing. Dr.techn. Zlatko Trajanoski

Betreuer: Dipl.-Ing. Michael Maurer

Betreuer: Dipl.-Ing. Robert Molidor

Graz, Oktober 2003

Diese Arbeit ist in englischer Sprache verfasst.

For my parents

Fur meine Eltern

Acknowledgements

I would like to thank my advisors Robert Molidor and Michael Maurer for their help during

this work. Their knowledge about JBoss and Struts was a great help.

In addition I would like to thank Bernhard Mlecnik and Martin Pirklbauer for testing my

software in the MARS, tmaWeb, and tmeWeb database.

Finally I would like to thank my family for supporting me with all their love and faith

during my entire studies. I would like to express my sincere gratitude.

iv

Abstract

The aim of this thesis was to develop an authentication and authorization system for as-

signing users a single account which can be used in web-applications, Microsoft© Windows

domains, and Unix/Linux servers. Currently all these miscellaneous systems are using their

own user management which leads to a time consuming and error prone account adminis-

tration. A consolidation of these proprietary technologies into a centralized system enables

administrators to get a quick overview about all users and their assigned access rights. All

needed configuration adaptations are conducted fast and efficient.

The developed system is based on the open source project OpenSymphony, which pro-

vides various Enterprise JavaBeans (EJBs) for the implementation of an authentication and

authorization system. The integration of Windows domain users is accomplished by a Samba

3.0 Server with a SQL extension. Furthermore Unix and Linux Servers are integrated by an

OpenLDAP 2.0.27/SQL server to get access to the centralized account administration. Other

applications are able to connect to the system with the developed client connector interface

independent from the used operating system and programming language. Several protocols

like HTTP, HTTPS, RMI, and SOAP are provided for this connection. Additionally this

client connector module allows applications to validate user logins, administrate users, and

their assigned access rights.

The integration of miscellaneous authentication and authorization technologies into one

central system makes this framework a valuable tool for flexible and efficient user and access

rights administration in heterogenous networks.

Keywords: Authentication, Authorization, Samba, LDAP, Java, OpenSymphony

Zusammenfassung

Das Ziel dieser Diplomarbeit war ein Authentifizierungs und Autorisierungssytem zu ent-

wickeln, um jedem Benutzer ein einziges Benutzerkonto zuzuweisen, das in Web basieren-

den Applikationen, Windows Domanen und Unix/Linux Servern verwendet werden kann.

Alle diese Systeme verwenden zur Zeit ein eigenes Benutzerverwaltungsystem, was zu einer

zeitaufwendigen und fehleranfalligen Benutzerverwaltung fuhrt. Eine Konsolidierung dieser

proprietaren Technologien in ein zentralisiertes System erlaubt es einem Administrator einen

schnellenUberblickuber alle Benutzer und deren Zutrittsrechte zu erhalten. Alle anfallenden

Konfigurationsanderungen konnen einfach und effizient durchgefuhrt werden.

Das entwickelte System basiert auf dem Open Source Projekt OpenSymphony, das ver-

schiedene Enterprise JavaBeans (EJBs) fur die Realisierung eines Authentifizierungs und

Autorisierungsystem zur Verugung stellt. Die Einbindung von Windows Domanen Benut-

zern wird durch die Verwendung eines Samba 3.0 Servers in Verbindung mit einer SQL

Erweiterung erreicht. Weiters erhalten Unix und Linux Server mit Hilfe eines OpenLDAP

Servers in Version 2.0.27 Zugang zu der zentralen Benutzerkontenverwaltung. Mit Hilfe

des entwickelten Client Connector Interfaces konnen sich andere Applikationen unabhangig

vom verwendeten Betriebssystem und angewendeter Programmiersprache mit verschiedenen

Protokollen (HTTP,HTTPS,RMI,SOAP) zu diesem System verbinden und so ihre Benutzer

authentifizieren. Weiters erlaubt das Client Connector Modul anderen Applikationen ihre

Benutzer und Zugangsrechte autonom zu verwalten.

Durch die Integration von verschiedenen Authentifizierungs- und Autorisierungstechno-

logien in ein zentrales System mit integrierter Kontenverwaltung wird diese Software zu

einem wichtigen Werkzeug fur die flexible und effiziente Benutzer- und Rechteverwaltung

in einem heterogenen Netzwerk.

Schlusselworter: Authentifizierung, Autorisierung, Samba, LDAP, Java, OpenSym-

phony

Contents

Glossary vi

1 Introduction 1

1.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Unix/Linux authentication process . . . . . . . . . . . . . . . . . . 2

1.1.2 Windows authentication process . . . . . . . . . . . . . . . . . . . 3

1.2 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Unix/Linux authorization . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Windows authorization . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Workstation management . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.1 Windows workstations . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3.2 Unix/Linux servers and workstations . . . . . . . . . . . . . . . . 5

2 Objectives 6

2.1 Account administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Authentication management . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Windows accounts . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Linux/Unix accounts . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.3 Other accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Authorization management . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Methods 8

3.1 Authorization management . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.2 Access Control Lists (ACL) . . . . . . . . . . . . . . . . . . . . . 9

3.2 Database development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

i

3.2.1 Database management systems . . . . . . . . . . . . . . . . . . . . 10

3.2.2 Structured Query Language (SQL) . . . . . . . . . . . . . . . . . . 12

3.3 Application server development . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Enterprise Java Beans (EJB) . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Application server architecture . . . . . . . . . . . . . . . . . . . . 13

3.3.3 Enterprise JavaBean-Query Language (EJB-QL) . . . . . . . . . . 15

3.4 Web application development . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1 Java Server Pages (JSP) . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.2 Custom tags and the JSP Standard Tag Library (STL) . . . . . . . . 18

3.4.3 Jakarta Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 OpenSymphony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.1 OSCore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.2 OSPropertySet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.3 OSUser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5.4 OSAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5.5 Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Samba server with MySQL backend . . . . . . . . . . . . . . . . . . . . . 24

3.6.1 Server Message Block protocol (SMB) . . . . . . . . . . . . . . . 24

3.6.2 Samba authentication . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.6.3 User profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.7 LDAP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.7.1 The Lightweight Directory Access Protocol . . . . . . . . . . . . . 26

3.7.2 Structure of an LDAP tree . . . . . . . . . . . . . . . . . . . . . . 27

3.7.3 Security in LDAP servers . . . . . . . . . . . . . . . . . . . . . . . 28

3.7.4 Authentication process using an LDAP server . . . . . . . . . . . . 28

3.7.5 LDAP servers with SQL-backend . . . . . . . . . . . . . . . . . . 29

3.7.6 Mapping between SQL and LDAP . . . . . . . . . . . . . . . . . . 30

3.8 Client connector protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.8.1 Java Remote Method Invocation (RMI) . . . . . . . . . . . . . . . 32

3.8.2 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . . . 32

3.8.3 SOAP and HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.8.4 Secure Socket Layer (SSL) . . . . . . . . . . . . . . . . . . . . . . 34

4 Results 37

4.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.2 Application authentication processes . . . . . . . . . . . . . . . . . . . . . 39

4.2.1 Authentication securing . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 The database model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 The administration web interface . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.1 Application administration . . . . . . . . . . . . . . . . . . . . . . 44

4.4.2 User administration . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.3 Group administration . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.4.4 Resource administration . . . . . . . . . . . . . . . . . . . . . . . 46

4.4.5 Access control lists administration . . . . . . . . . . . . . . . . . . 46

4.5 OpenLDAP server with SQL backend . . . . . . . . . . . . . . . . . . . . 48

4.6 Samba server configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7 LDAP client configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.8 Client connector software . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.8.1 Supported protocols . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.8.2 Client connector functionality . . . . . . . . . . . . . . . . . . . . 51

4.8.3 Client connector configuration . . . . . . . . . . . . . . . . . . . . 51

4.8.4 Client connector security . . . . . . . . . . . . . . . . . . . . . . . 53

4.8.5 Client authorization . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5 Discussion 54

Appendix 58

List of Figures

3.1 Location of an application server . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 An application server architecture overview . . . . . . . . . . . . . . . . . 14

3.3 A request and processing phase of a JSP . . . . . . . . . . . . . . . . . . . 17

3.4 An OpenSymphony architecture overview . . . . . . . . . . . . . . . . . . 23

3.5 Example implementation of an LDAP tree . . . . . . . . . . . . . . . . . . 27

3.6 Mapping between data and node . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 An entry of an LDAP tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.8 The object class mapping technique . . . . . . . . . . . . . . . . . . . . . 31

3.9 The hostname in the LDAP mapping . . . . . . . . . . . . . . . . . . . . . 31

3.10 The organization mapping in LDAP . . . . . . . . . . . . . . . . . . . . . 32

4.1 Authentication and authorization architecture overview . . . . . . . . . . . 38

4.2 The schematic authentication process . . . . . . . . . . . . . . . . . . . . 40

4.3 The developed database schema . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Screenshot: Welcome page of the web interface . . . . . . . . . . . . . . . 44

4.5 Screenshot: Information about web-applications . . . . . . . . . . . . . . . 45

4.6 Screenshot: User administration . . . . . . . . . . . . . . . . . . . . . . . 46

4.7 Screenshot: Create a new resource . . . . . . . . . . . . . . . . . . . . . . 47

4.8 Screenshot: Binding an access control list to a user or group . . . . . . . . 47

iv

List of Tables

3.1 An example Access Control List (ACL) structure . . . . . . . . . . . . . . 9

3.2 Example implementations of Access Control Lists (ACL) . . . . . . . . . . 9

3.3 The OSPropertySet technology . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 An example MD5 encrypted password . . . . . . . . . . . . . . . . . . . . 29

3.5 The summarization who uses public and private keys in ciphering . . . . . 36

v

Glossary

A

API Application Programming Interface, p. 18.

C

CGI Common Gateway Interface, a technology for creating dynamic web content,

p. 16.

E

EJB Enterprise Java Bean, a business data object specification developed in java tech-

nology, p. 20.

H

HTML HyperText Markup Language, describes static web pages, p. 17.

J

JAAS Java Authentication and Authorization Service, p. 22.

JDBC Java DataBase Connectivity, is an API that allows to access virtually any tabular

data source from the Java programming language, p. 16.

JNDI Java Naming and Directory Interface, is a standard extension to the Java plat-

form, providing Java technology-enabled applications with a unified interface to

multiple naming and directory services in the enterprise, p. 16.

JSP Java Server Pages, have been developed to provide an easy and intuitive way in

creating dynamical generated HTML pages, p. 16.

vi

L

LDAP Lightweight Directory Access Protocol, a technology to store data in a tree topol-

ogy, p. 18.

LDIF LDAP Data Interchange Format, describes a node in a LDAP tree, p. 28.

N

NIS Network Information System, a technology to authenticate Unix/Linux users in

a network, p. 22.

O

ODBC Open DataBase Connectivity, a tier to degenerate applications from DBMS,

p. 30.

P

PAM Pluggable Authentication Modules, a flexible mechanism for authenticating

users, p. 2.

PDC Primary Domain Controller, enables Windows users to authenticate in a domain,

p. 25.

POSIX Portable Operating System for unIX, a standard operating system interface, p. 31.

S

SASL Simple Authentication and Security Layer, a technology for adding authentica-

tion support to connection-based protocols, p. 50.

SMB Server Message Block, the Windows protocol for network file sharing, printing

services, etc., p. 24.

SOAP Simple Object Access Protocol, a lightweight protocol for exchange of informa-

tion in a decentralized, distributed environment, p. 32.

SSL Secure Socket Layer, a technology to enable a connection over a secure link,

p. 34.

vii

T

TLD Tag library descriptor, a descriptor of a custon tag library, p. 18.

TLS Transport Layer Security, technology to standardize a ’transport layer’ security

protocol, p. 50.

X

XML Extensible Markup Language, language to describe data, p. 20.

XPATH XML Path Language, XPath is a language for addressing parts of an XML doc-

ument, p. 20.

viii

Chapter 1

Introduction

The Bioinformatic Group (BIG) has developed several web based applications and databases

during the last years. As these applications are dealing with very heterogeneous data ranging

from molecular to highly sensitive patient related data, they all have implemented their own

proprietary user management system. This application focused user management approach

entails several disadvantages. It leads to additional implementation and development efforts,

may cause severe security leaks, increases the amount of maintenance, and the number of

passwords to be remembered. Additionally, the missing coherency between the existing

application specific accounts makes it impossible to link applications and their heterogenous

data, which is essential in biomedical research. In addition to various web applications most

of the members of the BIG are using Microsoft© Windows domain accounts for research

and development. Furthermore a number of Unix and Linux servers burden developers with

separate accounts.

Therefore a great improvement for users and administrators would be a system which

unites all existing accounts of a user to one. Users need to remember only one single account

and are able to use every application and workstation they are allowed to, with the same

username and password.

Moreover administrators will never lose track of accounts in the heterogenous network by

a single tool for administration. This centralized point of administration prevents forgotten

accounts and all accounts are encouraged with an expire date. Therefore a centralized user

management system improves security considerably.

1

CHAPTER 1. INTRODUCTION 2

1.1 Authentication

Authentication means that a user proves his identity. A familiar example is a username-

password combination. If a user is able to provide a valid password for a username (also

called a principal), then this user has demonstrated that it is a valid user of that username.

After a successful login process users get the status of an authenticated user.

Additionally to the often used username/password combination other technologies are

available to meet application or system specific requirements. For example, having a valid

user’s card is sufficient authentication for various systems. Some systems may require no

authentication at all, and others may require something as sophisticated as a retinal scan or a

DNA match.

1.1.1 Unix/Linux authentication process

Unix and Linux systems are using the Pluggable Authentication Module (PAM) technology

for an authentication process. The principal feature of a PAM approach is that an authen-

tication process is dynamically configurable. A system administrator is free to choose how

individual service-providing applications will authenticate their users.[18]

All PAM modules are implemented as dynamically loadable object files. Every appli-

cation, which needs to authenticate users, sets up a rule set for a login procedure. After

processing the precepts for an used application, aPAM assisted system grants or denies ac-

cess to the system. [33]

A major benefit of a modular configuration for a login process is that every application

has its own rules to grant or deny access. If a new application is added to the system, only a

new rule-set has to be appended. This module approach requires no recompilation ofPAM

supported system.

The benefits of modular login rules should be implemented in an authentication system.

The login process must have the following features:

• individually configurable

• changeable without a restart of the system

• independent from other applications


1.1.2 Windows authentication process

The authentication scheme on Windows NT, Windows 2000 and Windows XP machines is

set to LAN Manager (LM), which transmits and stores each user password hash using a one

way hashing algorithm. This increases security by storing only encrypted password hashes.

Modern Windows systems distinguish between four kind of login processes [9] :

interactive: Users login to a local computer to which they have physical access. Also

terminal services and remote desktop login processes are interactive even though they

take place remotely.

network: This login process contacts a system that is running Windows NT 4.0, Windows

2000, or Windows XP Professional across the network. The user data entered at the

interactive login process is used for a network login attempt.

service: When a Win32-based service starts up, it logs on to the local computer using the

credentials of a local or domain user account or the local system account.

batch: A batch login process is rarely used in the Windows operating system. It is reserved

for applications that run as batch jobs, such as bank account reconciliation and big

print spools.

Successful authentication is necessary, but not sufficient, to gain access to protected data.

After a security system authenticated a user successfully, the system must use this informa-

tion to determine the users access level.

1.2 Authorization

Authorization is the process of determining what a user is permitted to do. Different classes

of users can be given different privileges. This enables systems to divide users into several

access levels with different rights.

The concepts of authentication and authorization allows the construction of security sys-

tems that can be tailored to meet all needs of any class of users and any set of privileges.

They can be as simple or as complex as necessary.


1.2.1 Unix/Linux authorization

Linux systems provide a very simple and effective technique to implement fine grained ac-

cess control rights. Every file and directory has anownerand agroup. The privileges of a

user which is not the owner or member of the group, are set by theothersfield. These three

rights are controlled by three flags.

The following three flags are used:

• readable

• writable

• executable

If a user is not the owner of a file, the access level of the group is the determining factor.

Users inherit the access rights of the group.

1.2.2 Windows authorization

The Microsoft©Windows XP Professional operating system includes a number of features

that protect selected files, applications, and other resources from unauthorized use.

These features are [9]:

security groups: This enables administrators to divide users into groups with the same

access level. Grouping users helps to simplify the implementation and management of

the permissions and restrictions in applications.

access control lists (ACLs): There are two types of ACLs in Windows operating systems:

• Discretionary Access Control Lists (DACLs)

• System Access Control Lists (SACLs)

DACLs are used to identify users and groups that are allowed or denied access. SACLs

implement access rights to system components.

group policy: It is easier to manage groups than individual users. The rights granted to

a user are based on a user’s security group memberships. For this reason, a signif-

icant portion of Windows XP Professional operating system security is defined by

the default access permissions granted to the Administrators, Power Users, and Users

groups.


1.3 Workstation management

The institute network in the BIG contains Microsoft© Windows or Unix/Linux workstations

and servers. On the client side often Windows operating systems are used. On the other hand

server systems rely on Unix or Linux operating systems. This heterogenous network leads

to time consuming and error prone administration tasks.

1.3.1 Windows workstations

For the Microsoft©Windows workstations a Samba1 server acts as a Primary Domain Con-

troller (PDC). All members of the BIG are owners of an account for this domain. The PDC

provides access to the central institute fileserver.

Every user is a member of one of the four groups.

• Visitors

• Graduands

• Dissertant

• Post-Doc

The file server has special directories with special access rights to these groups. Visitors

get the lowest and Post-Doc the highest access levels.

1.3.2 Unix/Linux servers and workstations

Unix/Linux servers and clients are not member of a domain. There exists no equivalent

combination for Unix/Linux servers in the BIG. Every administrator of a server manages

its users individually due to the leak of a central Unix/Linux authentication server. This

burdens developers with several accounts to deploy their software on each server system.

Due to the separation into development and production servers developers need two accounts

during development process. It would be an improvement to assemble a central directory of

all Unix/Linux accounts in the institute network. Such a service enables administrators to

manage all Unix/Linux users identically as in a Windows domain.

1http://www.samba.org

http://www.samba.org

Chapter 2

Objectives

The aim of this thesis is to develop an authorization and authentication system which con-

trols all used accounts in the heterogenous network of the Bioinformatics Group. Therefore

existing user management systems and frameworks should be evaluated to develop a flexible

and standardized solution based on well established technologies.

The main goal is to develop a system that enables all servers, applications, and work-

stations in the BIG to share the same account data. Every user should own only a single

account which can be individually enabled or disabled on various applications, Windows

workstations and Unix/Linux servers.

2.1 Account administration

For the administration of all user data an easy to use web interface should be developed. An

administrator should be enabled to get a quick overview about all users and their according

access rights. With only a few clicks accounts should be enabled or disabled for every de-

sired application.

Administrators of applications should be able to administer their according accounts au-

tonomously. All common administration tasks like creating, deleting, and modifying of

accounts should only be accomplished by privileged users.

6

CHAPTER 2. OBJECTIVES 7

2.2 Authentication management

2.2.1 Windows accounts

Microsoft© Windows domain accounts have to be included into the developed authentication

system. All users of a Windows domain should be able to use their user management account

to get access to the institutes file server. An administrator must be able to enable or disable

Windows accounts individually and divide users in different groups according predefined

access levels.

2.2.2 Linux/Unix accounts

All development and production servers have to be integrated into this user management

system as well. All developers should be able to use their account on every Unix or Linux

server. An administrator of the authentication system should be able to enable or disable

accounts on all Unix/Linux servers individually. Users are only allowed to login to dedicated

servers.

2.2.3 Other accounts

Applications which need an authentication system should be able to connect to the central-

ized account pool to get access to all user data. A connection should not be limited regarding

to operating systems or used programming languages. All necessary administration tasks of

an application have to be accomplished autonomously.

2.3 Authorization management

An authorization management should be provided to all applications which need to protect

sensitive data against unauthorized users. Independent of all types of sensitive data an easy

to use mechanism should be provided to developers to guarantee that only authorized users

are able to get access. All administration operations should be manageable with an efficient

web interface.

Chapter 3

Methods

This chapter will give a brief survey of the technologies building up a platform independent

user management system. First an overview of authentication and authorization techniques

is given. Further sections present current Java technologies regarding to client-server ar-

chitectures. The layers of a web application are discussed as well as the client connector

interface to the user management system. Further the integrated OpenSymphony framework

is introduced. Finally the used Samba and OpenLDAP servers are presented to provide an

operating system independent authentication and authorization framework.

3.1 Authorization management

There are two essential parts of an authorization management system. Resources build up the

first and Access Control Lists (ACL) the second pillar. Applications need both techniques to

protect sensitive data to its users.

3.1.1 Resources

Applications which need to protect its content to users must map the topology of all sensitive

data to an authorization system. The structure of an application has to be translated into a

machine-readable form. Single units of a mapped data structure are called resources.

Application administrators can combine various parts of their data structure to resources.

These can be files, directories, web pages, methods of Java classes, or other sensitive objects.

For each resource one or more access rights may be used. In order to admit a resource, users

must own an appropriate access level. [39]

8

CHAPTER 3. METHODS 9

3.1.2 Access Control Lists (ACL)

In order to control admission to resources Access Control Lists (ACL) were developed.

ACLs define the access rights of users or groups to a resource. This technology provides

a very efficient and fine grained method to distribute access rights for users to resources of

applications.

ACL structure

Only a single resource can be managed by an ACL. Every ACL is owned by a single user

or group. Group rights are inherited to all members. ACLs are bound to an application,

resource, and user or group. Access permissions are denoted in a rights field of ACLs. [19]

application username groupname resourcekey access rightsmars fsmith plates RWD

Table 3.1:An example Access Control List (ACL) structure. Every ACL contains data fieldsfor an application, a resource, a user or group. This example is read as: “In theapplication mars, the user fsmith owns the access level read, write, and delete toa resource named plates.”

Binding ACLs to groups makes the administration more flexible. If an ACL is only con-

nected to a single user the amount of ACLs increases with every new user in an application.

This disadvantage can be avoided by linking access levels to groups and adding users to this

groups. The number of ACLs will be manageable and the overview of a rights management

system will never get lost. [38]

Example of an access control list

This example ACL implements three different access rights. Every right is represented by

an abbreviation. Read access is represented by “R”, write by “W”, and delete by “D”:

user-rights group-rights combined needed access rightsaccess grantednone RW RW R yes

R W RW D nonone D D DW yesRWD none RWD DW yesnone RWD RWD RWD yes

Table 3.2:Example implementations of Access Control Lists (ACL). Access rights of userand group are combined.

All rights of groups and users are combined via the logical “or” command. If a user does

not have sufficient access rights, group access levels are examined. All users inherit all rights


of their groups.

If a user has sufficient rights, group access levels are ignored. This redundant group

information is not used. User access levels have higher privileges than group permissions.

3.2 Database development

3.2.1 Database management systems

A database management system (DBMS) is a system that is designed to create, update, and

administer databases. The main purpose of a DBMS is the organization, efficient retrieval,

reliable storage, and maintenance of consistent data.

A DBMS must provide following features:

• persistence management

• concurrent access of users to data

• data recovery

• a data definition and data manipulation language (DDL/DML)

The logical data model, which is subject to a database, characterizes a DBMS. All com-

mon logical data models are listed below: [16]

relational: A relational DBMS (RDBMS) structures data into tables that have certain prop-

erties:

• Each row in the table is distinct from every other row.

• Each row contains only atomic data. In a relational model there is no repeating

data as arrays.

• Each column in the relational table defines named data fields or attributes.

A collection of related tables in a relational model assembles a database. The mathe-

matical theory of relations is subject to the relational model which was developed by

Edgar Codd in 1973. This model is the most popular one. Therefore most large-scale

applications are built upon a relation DBMS.


hierarchical: The hierarchical data model organizes data in a tree structure. There is a

hierarchy of parent and child data segments. This structure implies that a record can

have repeating information, generally in the child data segments.

In a hierarchical database the parent-child relationship is one to many (1:n). This

restricts a child segment to have only one parent segment. Hierarchical DBMSs were

popular from the late 1960s, with the introduction of IBM’s Information Management

System (IMS) DBMS, through the 1970s.

network: The popularity of the network data model coincided with the popularity of the

hierarchical data model. Some data were more naturally modeled with more than one

parent per child. A network DBMS permitted modeling of many-to-many relationships

in data. This model was formally definied In 1971.

The basic data modeling construct in the network model is a set construct. A set

consists of an owner record type, a set name, and a member record type. A member

record type can have that role in more than one set, hence the multiparent concept is

supported. An owner record type can also be a member or owner in another set. The

network model is based on the mathematical set theory.

object-oriented: An object-oriented DBMS (OODBMS) must be both a DBMS and an

object-oriented system. According to a DBMS it provides the capabilities mentioned

above. OODBMSs typically can model tabular data, complex data, hierarchical data,

and networks of data.

The following are important features of an object-oriented system: [16]

• complex objects - objects may be composed of other objects.

• object identity - each object has a unique identifier external to the data.

• encapsulation - an object consists of data and the programs (or methods) that

manipulate it.

• types or classes - a class is a collection of similar objects.

• inheritance - subclasses inherit data attributes and methods from classes.

• overriding with late binding - the method particular to a subclass can override the

method of a class at run time.

• extensibility - users may define new objects.

• computational completeness - A general purpose language, such as Ada, C, or

C++, is computationally complete. The Structured Query Language (SQL) does

not accomplish these conditions. Most OODBMSs incorporate a general-purpose

programming language.


flat: A flat file system is usually closely associated with a storage access method. Therefore

flat DBMS often use a file for storing data. This implies that users must know the

exact location of a data item in a record. In addition, flat files do not provide all

of the services of a DBMS, such as naming of data, elimination of redundancy, and

concurrency control. Further, there is no independence of the data and the application

program. The application program must know the physical layout of the data.

3.2.2 Structured Query Language (SQL)

Structured Query Language (SQL) is an American National Standards Institute (ANSI) stan-

dard computer language for accessing and manipulating database systems. SQL statements

are used to retrieve and update data in a database.

There are many different versions of the SQL language, but in order to be in compliance

with the ANSI standard, they must support the same major keywords in a similar manner

(such as SELECT, UPDATE, DELETE, INSERT, WHERE, and others). Many relational

database vendors have their own proprietary extensions in addition to the official SQL stan-

dard.

The part of SQL used to create databases is called the Data Definition Language (DDL).

Database maintenance is performed with the Data Manipulation Language (DML), and se-

curity is provided by the Data Control Language (DCL). [37]

3.3 Application server development

An application server is a component-based product that resides in the middle-tier of a server

centric architecture (see JBoss server in figure 3.1). It provides services for security and state

maintenance, along with data access and persistence. Java application servers are based on

the Java 2 Platform Enterprise Edition (J2EE).

Application servers provide the business logic of a web application. This logic is assem-

bled by using Enterprise JavaBeans (EJBs).

3.3.1 Enterprise Java Beans (EJB)

EJBs are server-side data objects which encapsulate the business logic of an application

written in Java. These objects are deployed to an EJB container which supports the Java 2

Enterprise Edition (J2EE) specification.


Figure 3.1:The application servers position in an application logic [26]. This figure showsthe location of the JBoss server in combination with several web servers anddatabases.

An application server provides containers to manage all bean instances and their lifetime

cycle. Developers do not have to worry about beans resources, transactions, security issues,

naming services and other administration tasks. The J2EE specification enables developers

to concentrate on the business logic and not on implementation details.

A major benefit of EJB is portability among various application servers which support

the J2EE specification. Developers write beans independent from the used application server.

3.3.2 Application server architecture

Developers are able to use different types of EJBs. The J2EE specification implements fol-

lowing three JavaBean types [26]:

Entity Beans: An entity bean represents a data object with an implemented persistence

mechanism. Persistence means that internal bean data is still available after a shut-

down of an application server, because all data of entity beans is stored in a database.

Entity beans provide developers an object oriented interface to create, delete, or mod-

ify entries in databases.

In the J2EE specification the underlying storage layer is a relational database. Entity

beans represent tables of databases to the business logic.

Two kinds of persistence mechanisms are available for entity beans.


Figure 3.2:An application server architecture overview. Various EJBs, like Entity, Session,and Message Driven Beans can be used by developers[1]

• Container Managed Persistence (CMP): This kind enables an EJB container to

care of synchronization between database and bean. Developers do not have to

worry about data consistency.

• Bean Managed Persistence (BMP): The second type of bean persistence imposes

developers to ensure data synchronization. Java DataBase Connectivity (JDBC)

enables developers to assure persistence. [6]

Session Beans:These beans are used by developers to describe the business logic. Clients

invoke session beans methods to read, delete or update data. They represent an inter-

face for clients to the application logic. Developers often interact with session beans

to get access to entity beans.

Internal states of these kind of beans are not stored persistent. All internal information

is lost after a crash or shutdown of an application server. [26]

Session beans may be subdivided into two groups:

• Stateless session beansdo not store their internal state among different method

invocations.

• Stateful session beanshold the client state across method invocations.

Message Driven Beans (MDB): MDBs are stateless, server-side, transaction-aware com-

ponents for processing asynchronous Java Message Service (JMS) messages. These

kind of beans were introduced in EJB 2.0.


Message-driven beans can receive JMS messages and process them. While a MDB

is responsible for processing messages, its container takes care of automatically man-

aging the component’s entire environment, including transactions, security, resources,

concurrency, and message acknowledgment. [25]

One of the most important aspects of message-driven beans is that they can consume

and process messages concurrently.

MDBs have bean classes and XML deployment descriptors, but they do not have com-

ponent interfaces. The component interfaces are absent because a message-driven bean

is not accessible via the Java RMI API. They respond only to asynchronous messages.

[26]

3.3.3 Enterprise JavaBean-Query Language (EJB-QL)

EJB QLis a declarative language like the Structured Query language (SQL) but it is designed

for the special abstract persistence schema of entity beans. [26]

Entity Beans with EJB-QL support (see section 3.3.2) are able to implementfindermeth-

ods in their deployment descriptor. This descriptor specifies the structure of afindermethod

to an application server. These finder methods are independent from the underlying database.

Developers specify in a deployment descriptor only what to find. No information of the used

database table structure is required.

J2EE certified application servers take care of the translation to the used database specific

SQL invocations. A developing process is not influenced by the used underlying database.

Example of an EJB-QL query

This example entity bean implements a single finder method “findByName”.

Signature:

public User findByName(String username)

Developers of container managed entity beans specify the finder method in the deploy-

ment descriptor of the bean. For this purpose EJB-QL is used. The following descriptor

implements the “findByName” finder:

<query>

<query-method>

<method-name>findByName</method-name>


<method-params>

<method-param>java.lang.String</method-param>

</method-params>

</query-method>

<ejb-ql>

SELECT OBJECT(o) FROM Usertable o WHERE o.name = ?1

</ejb-ql>

With this deployment descriptor a J2EE application server generates SQL queries. With

this technology there are no database specific SQL queries used by developers. Developers

of container managed beans are able to use another database vendor without changing all

entity beans and their deployment descriptors itself.

3.4 Web application development

3.4.1 Java Server Pages (JSP)

Java Server Pages (JSP) is a technology to develop dynamic web pages. It was first an-

nounced in 1999. Until now JSP has gone through two revisions and is available in version

1.2. [5]

JSP is a Java based technology. In fact, JSP is a part of theJava 2 Enterprise Edition

(J2EE)platform and can take advantage of Java Enterprise libraries, such as JDBC, JNDI or

EJBs.

Brief history of dynamic web content

In the early days of the Internet, the only tool to develop dynamic web content was the CGI

interface. CGI outlined how a web server can make user input available to a program, as

well as how the program provided by the web server with dynamically generated content is

sent back. CGI scripts are often written inPerl. However CGI is not a very efficient solution.

To generate a dynamic web page a web server has to create a new operation system process

with every request of an Internet user. This process has to load an interpreter, load a Perl

script, execute this script and build the web page.

A more efficient solution for this problem is theJava servlet technology. This technology

separates business logic code and the corresponding graphical elements. This alleviates the


development process for Java developers and graphic designers.

The Technology

JSP developers are able to generate dynamic content in web pages. Unlike Hyper Text

Markup Language (HTML), which is static and doesn’t change its content, JSPs are able

to change its content on any number of variable items, including the identity of users, type

of browsers, date or other information provided by visitors of web pages.

JSPs contain standard markup language elements, such as HTML tags, just like a regular

HTML page. The specification of JSP also contains special elements that allow web servers

to insert dynamic content in a web page. JSP elements can be used for a variety of purposes,

such as retrieving information from a database or registering user preferences.

Request processing

If users ask for a JSP, the server executes all JSP elements, merges their results with the static

parts of a web page, and sends a dynamically composed page back to the client browser.

Figure 3.3:A JSP is compiled to a servlet before it is processed the first time. Further re-quests are handled by the generated servlets. This technology speeds up theprocessing of requests. [5]

A JSP site is always compiled to a servlet before it’s processed the first time by a server.

This is an important benefit from this technology. It speeds up the processing on high loads

of a web server. A server does not have to load an interpreter neither to parse nor to execute

a script. All further requests are handled directly by the generated servlet.


JSP Advantages

Major benefits of the JSP technology are:

• JSP supports both scripting- and element-based dynamic content and allows develop-

ers to use custom tag libraries to satisfy application-specific needs.

• JSP are compiled for efficient server processing before the first request

• JSP is a specification not a product. This means many vendors can compete with

different implementations, leading to better performance and quality.

• JSP is an integral part ofJ2EE. This means JSP has a broad range of being used in

web-applications. Developers can use JSP on even the simplest applications up to the

most complex enterprise solutions.

As mentioned before developers are able to extend the functionality of JSPs by creating

own tags. These new elements are calledcustom tags.

3.4.2 Custom tags and the JSP Standard Tag Library (STL)

Custom tag librariesallows page authors to encapsulate often needed functions into HTML-

like elements. A page author can use new tag elements in the same familiar way, a Java

programmer develops new actions based on Java classes. Such actions are calledcustom

actionsand have access to all information about a web-browsers request. It is possible to

add content to response bodies as well as set response headers. A custom tag is inserted

into web pages using HTML-like elements. The attribute values passed to an action are

influencing the internal state of these elements and are able to manipulate the control flow of

the tag.

Within a custom action arbitrary Java Application Programming Interfaces (API) can be

used by a developer to access external resources. Actions are able to use databases with Java

DataBase Connectivity (JDBC), connect to Lightweight Directory Access Protocol (LDAP)

servers (see section 3.7) or send emails over a mail server. [5]

The way a JSP container interacts with a custom action makes it possible to conditionally

process its body and to abort the processing of the rest of a web page. A custom action is

implemented as a Java class. The name of a class and other additional information that the

container needs to invoke a custom tag, are specified in a file called Tag Library Descriptor

(TLD). A custom tag library is a simple collection of TLD and all other files for a related set

of custom actions. In most cases, all TLDs and used classes are packed in ajar file. This

makes it easy to install custom tags. [4]


3.4.3 Jakarta Struts

One of the well-established and most powerful frameworks for building web applications

with Java servlet and Java Server Pages (JSP) technology is the Jakarta Struts project. This

open source project encourages developers to build up applications based on the Model-

View-Controller (MVC) paradigm [14].

Location of the Jakarta Struts framework

The Struts framework resides in the web tier. Struts web applications are hosted by a web

container and can make use of service protocols provided by a container. This behavior of

Struts lets a container handle all incoming HyperText Transfer Protocol (HTTP) or Hyper-

Text Transfer Protocol Secure (HTTPS) requests. This technology enables developers to

focus on the web development rather than on processing of client requests. [8]

The Model View Controller (MVC)

The Jakarta Struts framework provides a way to separate the presentation from the business

logic and the request processing. A web application using this MVC pattern is easier to

maintain and more extensible than comparable applications built with another architecture.

[23]

TheMVC pattern is categorized as a design pattern in many software design books (see

[14] and [6]). Although there is much disagreement on the precise definition of the pattern,

the following ideas are fundamental:

Model: This part is responsible for the business logic. A model can take many different

forms. In a two-tier application, where a web tier interacts directly with databases to

load or store data, the model classes may be directly implemented java objects.

In more complex enterprise applications a web-tier often uses an EJB server (see sec-

tion 3.3). With an EJB server the model consists of Enterprise JavaBeans (EJBs). A

web tier does not communicate directly with the data entries but rather with session

beans. Received data of EJBs is transfered to the view to represent dynamically web

pages.

View: This part is responsible for the presentation view of an application. All views within

a web tier consist of HTML and JSP pages. For static content HTML pages are used,

while for dynamic content the JSP technology is taken. Most dynamic content is gen-

erated in the web tier. It is possible to useJava-Scripton the client-side. This does not

interfere with or infringe upon the MVC concept.[23]


Controller: Controllers manage the flow and the state of an application based on actions

of users. The part of the controller in Jakarta struts is aJava servlet.

The controller in a web application tier performs the following duties:

1. Intercepts HTTP requests from a client

2. Translates a request into a specific business operation

3. Either invokes a business operation itself or delegates it to a handler

4. Helps to select the next web page which will be displayed at a client

5. Returns the view to a client

3.5 OpenSymphony

OpenSymphony is an open source Java framework for web based applications. The project

is intended to assist web application developers with APIs, EJBs, servlets, and JSP tags.

Often used functions in web applications are handled by OpenSymphony. This framework

accelerates the developing process and implementation efforts can be focused on the business

logic of new applications.

The framework is split up into the following four major modules:

3.5.1 OSCore

OSCore is a set of core utility-classes and modules that are used by other components of

OpenSymphony. They are building the fundament of this open source project. Enterprise

Java Beans (EJB) and Java Naming and Directory Interface (JNDI) utilities are also in this

OSCore package. These are helpers for common tasks with entity and session beans. Fur-

thermore often used functions in application server development are handled by this module.

OSCore contains classes for manipulating strings, handling eXtensible Markup Language

(XML) files, or transforming XML files with XPATH1.

3.5.2 OSPropertySet

The OSPropertySet is a module to enable developers to store miscellaneous information

with a key-value pair combination in a database. Arbitrary information can be stored in-

dependently of the type of data. Developers need not to worry about databases or SQL

statements.1http://www.w3.org/TR/xpath

http://www.w3.org/TR/xpath


Each pair consists of a unique key and a corresponding value. A pair is stored in a

corresponding data type specific table in the relational database.

All keys are represented as a unique string. Due to a unique key all data can be found

easily in a database table.

Following types of data can be handled by OSPropertySet:

• Integer

• String

• Float

• Date

• Boolean

key value data type of tableusername Frank Smith string databirthday 04.12.1979 date data

Table 3.3:An example of storing a string and date property with a key-value pair

3.5.3 OSUser

OSUser is a module of the OpenSymphony framework designed to provide an API for a

simple to use authentication and user management system. This module allows to manage

users, groups, and group-memberships.

OSUser does not manage access levels of users to resources (see section 3.1.1). Only

information to authenticate users is stored by this module. Data to users are handled by a

OSPropertySet module. This enables the OpenSymphony framework to store any informa-

tion needed by users.

An authentication process of users to an application is accomplished within OSUser.

Username and password of users can be managed by external authentication systems. OS-

User can be connected to external authentication system by so called “pluggable providers”.

Pluggable providers

An OSUser module provides a simple interface for an authentication process. Developers

have the choice to get corresponding authentication data from a number of data sources.


OSUser contains providers for a number of popular user management systems, such as

relational databases, XML files, Lightweight Directory Access Protocol servers (LDAP),

Unix/NT users, Network Information Systems (NIS), Pluggable Authentication Module

(PAM), Java Authentication and Authorization Service (JAAS) providers, and proprietary

systems of common applications and servers such as Orion2, WebLogic3, Resin4, Tomcat5,

JBoss6, Jive7, and Jetspeed8.

3.5.4 OSAccess

OSAccess provides a centralized entitlement engine for this framework. This module man-

ages all information of resources an application implements. Furthermore all ACLs of users

and groups are handled within OSAccess.

OSAccess enables developers to:

• arrange fine grained access levels for individual resources

• establish protection at user or group level to resources

Resources are the basic components of this authorization technology (see section 3.1.1).

ACLs must be linked to a user or group to provide access to resources.

Linked ACLs establish a fine grained authorization management. General access levels

can be bound to groups and special rights (e.g. to do administration tasks) to special users.

3.5.5 Architectural overview

The diagram 3.4 illustrates the overall architecture of the various modules and how they

interact.

OSCore is the base of all packages. All other components are using functions of this

module. The presented OSUser, OSAccess, and OSPropertySet are located in the business

tier of the OpenSymphony project.

2http://www.orionserver.com/3http://www.bea.com/products/weblogic/server/4http://www.caucho.com/5http://jakarta.apache.org/tomcat/6http://www.jboss.org/7http://www.jivesoftware.com/8http://jakarta.apache.org/jetspeed/

http://www.orionserver.com/

http://www.bea.com/products/weblogic/server/

http://www.caucho.com/

http://jakarta.apache.org/tomcat/

http://www.jboss.org/

http://www.jivesoftware.com/

http://jakarta.apache.org/jetspeed/


Figure 3.4:The OpenSymphony architecture is split into several layers. OSCore is the baseof all other modules. All major components are located in the business tier.OSAccess and OSUser assemble a basic authentication and authorization frame-work. [7]


3.6 Samba server with MySQL backend

A Samba9 server can be used to manage user accounts of a Microsoft©Windows domain,

providing printing, and file sharing services in a network.

A domain is a collection of computers in a network where security is handled centrally.

Each domain has one or more controllers. Usually there is a Primary Domain Controller

(PDC) and several backup domain controllers. The domain controllers maintain account

style information related to users (clients), like account names, encrypted passwords, autho-

rized hours of use, or groups the user belongs to. Samba servers implement their own file

based database. All usernames and passwords can be stored in a simple file. It is also possible

to use a relational database as a datasource. A Samba server in version 3.0 can be configured

to use a MySQL10 DBMS as backend database. To enable a connection between MySQL

and Samba the mysql-password-backend module of the Samba project is used. This module

can be activated in the server configuration file. A Samba server is a free implementation of

the Server Message Block (SMB) protocol. [31]

3.6.1 Server Message Block protocol (SMB)

The Server Message Block (SMB) protocol is for sharing files, printers, serial ports, and

communications abstractions such as named pipes and mail slots between computers. [36]

This protocol was developed by Microsoft and IBM beginning in 1985. It was inherit

from the IBM PC Network SMB Protocol.

SMB is a client server, request-response protocol. Clients make a request to the server

which generates a response. Clients connect to servers using TCP/IP as specified in

RFC100111 and RFC100212. Once clients have established a connection, they can send com-

mands to the server that allow them to access shares, open files, read and write files, and

generally do all sort of tasks that can be done to a local file system.

A SMB protocol can be used not even with Microsoft operating systems. There are free

server implementations available. One of the most established free implementations of SMB

is the Samba project. There are several reasons for using a Samba server to replace Windows

NT machines in a network:

• Samba is very stable

9http://www.samba.org10http://www.mysql.com11http://www.faqs.org/rfcs/rfc1001.html12http://www.faqs.org/rfcs/rfc1002.html

http://www.samba.org

http://www.mysql.com

http://www.faqs.org/rfcs/rfc1001.html



• less expensive computers and ”legacy”equipment is needed

• no client or server licenses are necessary

• integration with MacIntosh’s is possible

The functionality of a Samba server in version 3.0 is [21] :

• domain log-ons for Windows NT 4.0/2000/XP clients

• placing a Windows 9x client in user level security

• retrieving a list of users and groups from a Samba Primary Domain Controller (PDC)

to Windows 9x/NT/2000/XP clients

• roaming (roving) user profiles

• Windows NT 4.0-style system policies

3.6.2 Samba authentication

A SMB server uses two different passwords to authenticate users. Both passwords hashes

are calculated from a user password.

LANMAN password hash: This password is encoded as a 32 hex digit. A LANMAN hash

is created by Data Encryption Standard (DES) encrypting a well known string with an

users password as DES key. Windows 95/98 workstations are using this kind of pass-

words. LANMAN encrypted password are not using a “salt” value like Unix/Linux

MD5 passwords. This leads to weaker password hashes. Two identical passwords of

users are represented by the same hash value.

If a user has a null password, the password field will contain the characters “NO PASS-

WORD” as the start of the hex string. If the password hex string is equal to 32 ’X’

characters then a users account is marked as disabled and users will not be able to login

to a Samba server. [2]

NT password hash: This is the Windows NT hash of a users password, encoded as 32

hex digits. Windows NT password hashes are created by taking a users password as

represented in 16-bit, little-endian UNICODE and then applying a MD4 (see [29])

hashing algorithm to it. This algorithm uses no “salt” value for its calculations. MD4

calculated hashes lead to identical hashes for identical user passwords. [2]


3.6.3 User profiles

A Samba server must act as a PDC to provide user profiles. Acting as a PDC a Samba server

is able to process login requests, and store roaming profiles. Therefore users are able to

login in every computer in a domain and still use their familiar desktop on every Windows

workstation. [32]

Roaming profiles

A roaming profile of a user can be specified in a Samba configuration file. This roaming

profiles store user specific information on the server side. If a user logs out of a workstation

the profile information is updated. Data like background images are stored in a roaming

profile. [32]

Mandatory profiles

These are profiles as roaming profiles but they are only writable for administrators of do-

mains. Normal users are only able to read mandatory profile informations. A user can have

a unchangeable profile with this type. [32]

Login scripts

A Windows system can execute scripts and commands if a user logs in. These scripts are

called login scripts. They can be used to connect to network folders or update anti virus

software from a server. It is possible to substitute various entries in a login script by e.g. the

username. [32]

3.7 LDAP server

3.7.1 The Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol (LDAP) is used to share data over a network

which is stored in an information directory. All data is stored in a tree topology, optimized

for read access. [11]

Data structures of an LDAP server are represented as a tree topology. Data is ordered

hierarchically based on a directory record’s distinguished name (DN). A DN is a unique id

of each entry stored in an LDAP tree. All entries in an information directory are linked to a


root node. This node is calledbase DN. Root nodes consist of an inimitable string, oriented

at a unique name or Internet address. [28]

A major advantage of the protocol is the implementation on almost any platforms and the

acceptance of LDAP in the industry. Clients do not have to worry about operating systems

or vendors of servers.

3.7.2 Structure of an LDAP tree

This technology builds up a tree structure which can be easily modified and adopted to the

needs of the internal structure of an institute or corporation. The root DN is formed by

a unique name. The base DN from the Bioinformatics Group would be dc=genome,dc-

=tugraz,dc=at. This DN is inherited from the Internet address of the institutes home page.

Root nodes are an entry point for other organization units (OUs) like departments or other

sections of this institute. Additionally OUs are linked directly to a DN. An OU “people” is

used to store general user data into an LDAP tree. User data is stored in a Common Name

(CN) node. Such a CN contains object classes of a user.

Object Classes (OCs) define the kind of information an entry in a CN node stores. OCs

again specify attributes of a CN node. Any attributes consist of a type and a corresponding

value. An attribute of a user object class could be username, full name or email address.

Entries in an LDAP tree can assign as many object classes as applicable to any given type

of object.

Figure 3.5:Example implementation of an LDAP tree for a cooperation or institute. Orga-nization Units (OU) link to a root node (DN) to build up a tree topology.


3.7.3 Security in LDAP servers

All nodes in LDAP trees can be protected with Access Control Instances (ACI). Such an

ACI controls the admittance to nodes based on usernames, Internet Protocol (IP) addresses,

or other informations of a caller. Fine grained access management can be implemented

server-sided to protect each node in an LDAP tree. [11].

3.7.4 Authentication process using an LDAP server

If the user “fsmith” starts an authentication process, the users LDAP-client is looking for an

entry with a matching CNcn=fsmith,ou=people,dc=genome,dc=tugraz,dc=atat the server.

This node must be an inimitable node within a requested LDAP server tree. If the node is

found by the user’s login system, all attributes of the corresponding user’s node is read out

and sent to the client system.

A login process of Unix/Linux users needs aposixAccountas object class. This OC needs

attributes likeuid, uidnumber, gidnumber, homedirectory, loginshell and userpassword.

An entry of a typical user node presented in LDAP Data Interchange Format (LDIF):

dn: uid=fsmith, ou=people, dc=genome, dc=tugraz, dc=at

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

objectclass: posixAccount

uid: fsmith

givenname: Frank Smith

sn: Frank

cn: Frank Smith

telephonenumber: 510-555-1234

roomnumber: 122G

mailRoutingAddress: [email protected]

mailhost: mail.genome.tugraz.at

userpassword: {crypt}3x1231v76T89N

uidnumber: 1234

gidnumber: 1200

gecos: Frank Smith

homedirectory: /home/fsmith

loginshell: /usr/local/bin/bash


This LDIF entry represents a Linux/Unix POSIX account. This object class needs pass-

words based on the MD5 algorithm.

MD5 encrypted password hashes

Linux/Unix systems are using MD513 encrypted hashes for storing passwords. This algo-

rithm uses a so called crypt14 function of Unix/Linux systems. This function needs a “salt”

string for its calculations. Before generating a new password hash, six random characters

are chosen for a salt string. The first three characters in a password hash (“$1$”) are con-

stant. The six random salt characters assemble the second part of a new password hash to

recapitulate calculations at a login process.

clear text password salt string entry in databasefoopass KFkfqV $1$︸︷︷︸

1

KFkfqV︸︷︷︸2

Sd$wfusKu8b2dMIkJOqk5KFO/︸︷︷︸3

1→ constant string2→ salt string3→ MD5 encrypted salt string and password

Table 3.4:an example MD5 encrypted password

A salt-string is necessary for generating unequal encrypted hash values if users choose

equal passwords. [30]

Secure connection between server and client

All usernames and passwords are transited over a network connection during a login process

if a client logs into his or her client workstation. Security increases if all LDAP requests are

encrypted. All state-of-the-art LDAP servers support the Simple Authentication and Security

Layer (SASL) and the Transport Layer Security (TLS) protocol. Due to this enhancements

all passwords are not sent in plain text over a network. [3] [15]

3.7.5 LDAP servers with SQL-backend

An LDAP server can be configured to use a RDBMS for storing its internal data. The topol-

ogy of the LDAP tree is not different from a server with a usual file based database. Only

the kind of storing informations is changed.

13http://www.ietf.org/rfc/rfc1321.txt14http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?crypt+3

http://www.ietf.org/rfc/rfc1321.txt

http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?crypt+3


Normal LDAP servers use a file based database as the data backend. LDAP servers with

SQL-backends keep its information in tables of a relational database.

To select a RDBMS as storage container, a back-SQL module is configured by the ad-

ministrator of an LDAP server. The server is not connected directly to the RDBMS. For

this purpose a link is established via an Open DataBase Connectivity (ODBC) connection.

Nearly every vendor of RDBMS provides an ODBC driver to its database. An ODBC tier

separates the database from the LDAP server and makes both independent of each other. De-

velopers write code only for an ODBC tier and not to a special database vendor. Customers

of this code are able to choose any database vendor which provides an ODBC driver.

Relational DMBS are using tables for storing data and LDAP server use a tree topology.

To connect both structures, a mapping mechanism must be used.

3.7.6 Mapping between SQL and LDAP

Mapping between an LDAP and SQL statement is done by five tables in a SQL database.

These tables enable LDAP servers to assemble SQL statements to get required data from a

relational database [27].

All names of these five tables are determined by the LDAP server and must not be

changed. The five names are:

ldap attr mappings: This table is mapping any common name entry (see section 3.7.2) to

a database entry. The red circle in figure 3.6 denotes: this entry is a Portable Operating

System for unIX (POSIX) account (the Primary Key (PK) “1” in the ldapoc mappings

table is a POSIX-account). All other tables convert attributes from an LDAP schema

to a corresponding table and column in a used SQL database. The line with id “1”

Figure 3.6:The mapping between node and data location in the database is accomplished inthis table

configures an LDAP server to get the attribute “dn” from a table calledos userand the

select statement takes a columnos user.name.


ldap entries: Each user is represented by a DN entry in an LDAP tree. This entry is located

in the ldapentries table. The red ellipse in figure 3.7 marks the DN primary key of a

tree node. The node with the PK in the blue circle is the root of the tree a user belongs

to. All user data can be found in the table osuser (see figure 3.7) with the PK marked

in the purple circle.

Figure 3.7:Each entry in an LDAP tree is stored here. Each entry represents a node.

The blue ellipse defines an entry as a POSIX-account. A POSIX-account has a primary

key “1” in a ldapentry objclasses table.

ldap oc mappings: This table (see figure 3.8)contains all object classes provides by an

LDAP server. All PKs of object classes are used in the table ldapentries above.

Figure 3.8:All object classes (OC) provided by a server are located in the osmapping table.

ldap referrals: The name of the organization is stored in this table (see figure 3.9).

Figure 3.9:The hostname of the server is stored in ldapreferrals.

organization: The base dn entry of an LDAP tree is stored in this table (see figure 3.10).


Figure 3.10:The organization of the server is stored in this table.

3.8 Client connector protocols

3.8.1 Java Remote Method Invocation (RMI)

Java Remote Method Invocation (RMI) enables developers to create distributed Java appli-

cations, in which the methods of remote Java objects can be invoked from other hosts. A

Java method can make a call on a remote object once it obtains a reference to the remote

object. Applications can use one of two mechanisms to obtain references to remote objects.

An application can register its remote objects with RMI’s simple naming facility, thermireg-

istry, or the application can pass and return remote object references as part of its normal

operation. [24]

3.8.2 Simple Object Access Protocol (SOAP)

Firewalls often block connections over unusual ports to the Internet for security reasons.

These open ports could be used by attackers, viruses or Trojan horses. To establish a connec-

tion over a intermediary firewall the Simple Object Access Protocol (SOAP) is used. SOAP

is a simple XML based communication protocol between applications using HTTP. Connec-

tions between SOAP-enabled servers are established over a TCP link with configurable ports.

Often port 80 is used by SOAP. This port is used by web browsers and so far not blocked by

firewalls. [10]

SOAP was developed to provide a communication protocol between applications that

need a standardized way of sending and receiving messages independent of operating sys-

tems or programming languages. SOAP has been designed and approved by the World Wide

Web Consortium (W3C). It became aW3Cstandard in May 2000. [13]

3.8.3 SOAP and HTTP

A SOAP method is a HTTP request/response that complies with SOAP encoding rules. The

port of a SOAP request is individually configured by the needs of an application.


An example of a SOAP request and response : [10]

The request

POST /InStock HTTP/1.1

Host: www.usermanagement.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.usermanagement.org/userinfo">

<m:GetUsersFullname>

<m:UserName>fsmith</m:UserName>

</m:GetUsersFullname>

</soap:Body>

</soap:Envelope>

The response

HTTP/1.1 200 OK

Content-Type: application/soap; charset=utf-8

Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.usermanagement.org/userinfo">

<m:GetUsersFullnameResponse>

<m:Price>Frank Smith</m:Price>

</m:GetUsersFullnameResponse>

</soap:Body>


</soap:Envelope>

3.8.4 Secure Socket Layer (SSL)

A connection between server and client is encrypted for security reasons with a Secure

Socket Layer (SSL) protocol.SSLwas published in 1995, it paved a way for broad pub-

lic access to online information security.SSLis an encryption technology that scrambles a

message so that only a recipient of the message is able to unscramble it.

Such a security protocol has become very important for applications that transfer criti-

cal information such as personal data, passwords, credit card numbers, or Internet banking.

These data must be protected against unauthorized access. [17]

Anyhow, SSLhas some limitations in real world use. Even if the protocol layer is in-

stalled and enabled on a server, users must use aSSLcompliant browser, but any modern

browser supports this feature. [20]

To getSSLworking all servers need a digital ID (also known as an authentication certifi-

cate) from a trusted third-party source that can vouch for its identity. A certificate is used to

verify the identity of a server. Such third party certificates can be acquired from companies

like Verisign15. [17]

TheSSLprotocol uses a public key encryption. This technology was developed by Diffie

and Hellman in 1976.

The public key cryptography concept

Public-key cryptography uses a pair of mathematically related cryptographic keys. If one

key is used to encrypt private information then only the related key can decrypt that data. It

is not possible to calculate the opposite key in a maintainable time, if only one key is known.

As a result, the following two keys are used in a “public key system”: [22]

A public key: is published for the publicity

A private key: is the secret and not published counterpart

15http://www.verisign.com/

http://www.verisign.com/


Using the public key If confidential information should be sent from person “A” to person

“B”, Person “A” uses the public key of Person “B”, which has been published on an Internet

page or a directory service, to encrypt the information. Only person “B” can decrypt a

scrambled message by using the own private key16.

Using the private key A private key is used to decrypt information that has been encrypted

by its corresponding public key. A person using the private key can be certain that informa-

tion is not seen by a third party, but a sender of a scrambled message can not be verified with

this method.

Using the private key for signatures If a sender wishes to prove his identity to a recipient

of a message, the private key is used to digitally sign a message (like a digital signature).

Unlike a handwritten signature, this digital signature is different every time it is made.

A hash value of a message is calculated and this value is encrypted with the private key

of a sender. The encrypted value is either attached to the end of the message or is sent as a

separate file together with the message. The public key corresponding to its private key may

also be sent with the message, either on its own or as part of a certificate. [22]

Anyone receiving information which is protected simply by a digital signature can check

the signature and can read and process the information. Adding a digital signature to mes-

sages does not provide confidentiality.

Verifying signatures A receiver of a digitally signed message uses the correct public key

to verify a signature by performing following steps. [22]

1. A correct public key is used to decrypt a hash value that the sender has calculated for

its message.

2. A hash value of a received information is calculated by using the same hashing algo-

rithm.

3. This newly calculated hash value is compared to the hash value that the sender orig-

inally calculated. This was found in the step above. If all values match, a receiver

knows that the person controlling the private key corresponding to the public key, sent

16In normal practice, the actual information being sent is encrypted using a secret key algorithm (symmetriccryptography). Symmetric algorithms are much faster than public/private key algorithms (asymmetric cryptog-raphy). A random key (the session key) is generated, and it is used with the symmetric algorithm to encrypt theinformation. A public key is then used to encrypt that key and both are sent to the recipient. [22]


the information. A receiver also knows that the information has not been altered since

it was signed.

4. If a public key certificate was sent with the information, it is validated with the certifi-

cate that issued the certificate to ensure that the certificate has not been falsified and

therefore the identity of the controller of the private key is genuine.

5. Finally, if one is available, the revocation list for a certificate is checked to ensure that

a certificate has not been revoked, or if it has been revoked, what the date and time of

revocation were.

The following table summarizes who uses public and private keys and when:

Key function Key Type used byEncrypt data for a recipientPublic key of recipient Receiver

Sign data Private key of sender SenderDecrypt data received Private key of receiver Receiver

Verify a signature Public key of sender Sender

Table 3.5:The summarization who uses public and private keys in ciphering

Chapter 4

Results

This chapter will present the developed database model for all necessary components of

an operating system independent authentication and authorization system. Furthermore the

corresponding administration web application will be shown. Also all used servers and their

configuration for providing a user management framework will be explained. Finally the

developed client connector interface is professed.

The evaluation of existing user management systems has yielded to the result, that no

existing system satisfies all requirements for an operating system independent authentication

and authorization framework. The best starting position provided the open source OpenSym-

phony project. The developed system is based on this project.

4.1 Architecture overview

The authorization and authentication system is divided into six main parts (see figure 4.1)

which interact together to provide a single account for each user. This account can be used

on every web application, development server, and Windows workstation at the BIG.

MySQL database: All necessary data for this authentication and authorization system is

stored in the central MySQL1 database. This open source database was used because

the used Samba server needs a SQL-backend module which is only implemented for

the MySQL database. This DBMS is performant, well established, freely available,

and supports many operating systems. MySQL is available for Linux, FreeBSD, So-

laris, Windows and OS/2 operating systems.

Samba server: This server acts as a Primary Domain Controller (PDC) for a Windows

1http://www.mysql.com

37

http://www.mysql.com

CHAPTER 4. RESULTS 38

Figure 4.1:Architecture overview of the authentication and authorization system. Six mainparts assemble an operating system independent user management system. AMySQL server builds the database backend. The JBoss application server residesin the middle tier and a Jakarta Tomcat web server assembles the presentationtier. Arbitrarily applications are able to connect to this framework and get accessto this user management system by the client connector interface. Administrationtasks are conducted with the web-interface. A Samba server acts as a PrimaryDomain Controller (PDC) in a Windows domain. Unix/Linux users are able touse the OpenLDAP server for authentication processes which is connected viaan Open DataBase Connectivity (ODBC) tier to the MySQL database.


domain. Windows 98, NT and XP users are able to store their windows user profile at

this server and therefore work with their familiar desktop settings on every workstation

in the BIG. The used Samba server is equipped with a SQL-backend to receive user

data from the centralized DBMS. MySQL is the only DBMS vendor who supports this

SQL-backend module.

OpenLDAP server: An LDAP server enables Unix/Linux servers or workstations to get

access to all accounts of this user management system. The used host is equipped

with a SQL-mapping-backend. A SQL-backend enables this server to connect to the

central MySQL database used in this framework. The mapping from LDAP statements

to SQL queries is done by the LDAP-SQL mapping described in section 3.7.6.

JBoss application server: A JBoss application server hosts the application logic of the

developed authentication and authorization system. The OpenSymphony project pro-

vided the basis of the developed business logic. All actions are implemented as EJBs

and deployed into this server.

Tomcat webserver: This server handles the developed web interface for all administration

tasks. The authentication and authorization system is managed and monitored over

easy-to-use web pages.

Client connector interface: This package allows applications to connect to the developed

user management system to validate user authentications and to administer their ap-

plication specific data. Four protocols enable developers to establish a connection to

the user management system. The interface is independent from the used operating

system and programming language.

4.2 Application authentication processes

Users need to enter their username and password in a login form during an authentication

process. This provided information is compared with a stored value in the database. After a

successful validation of username and password, users get the status of authenticated users.

4.2.1 Authentication securing

In order to guarantee a successful login attempt the authentication id is used. Right after a

successful login process, a unique identifier is generated for each user and sent back to the

client application. Each client stores the received user associated id and transmits it back


with every request to a protected resource. With every request the user management server

compares the client and the server-side generated authentication id to prove a earlier valid

login process. Only if both id’s are equal user access rights are controlled (see figure 4.2).

Figure 4.2:The schematic authentication process of the authentication system. The id isgenerated server-sided after a successful login attempt and sent back to the client.Each invocation of a client contains this id to verify the authentication process.Only if both id’s are equal user access rights are controlled.

Authentication rules

These rules contain all precepts a user must accomplish before access is granted and must be

assigned to each application. Authentication rules can be changed dynamically and only by

users with application administrator status.

All rule-sets are XML based and able to use user properties (see section 3.5.2) which

are located in the central database to validate authentication attempts. Besides a password

check, other free configurable rules can be controlled during a login process. [34]

Available login rule-sets

Following four rules are used to validate user login attempts:

String Token: A user is only allowed to login if this user has a corresponding string-

property, which matches a given string in the token. E.g. an administrator can draw up


a rule that only users with the home town “vienna” are allowed to authenticate.

Date Token: This rule checks arbitrary date properties of users. The validity of accounts is

controlled by corresponding start and expire dates by this rule.

Password Token: The password rule compares the password with the corresponding hash

value of the user password stored in the database. This is an essential rule for almost

every application which uses authentication.

Integer Token: The property of type integer is compared with the property given in this

rule-set. This compared user property has to be of type number (see section 3.5.2).

The rule-set syntax

All tokens are loaded in succession and if a single token fails, the whole login process is

aborted. Anid attribute of a token declares a key of a property in the database. Theresult

attribute allows administrators to declare the required results of comparisons of user proper-

ties.

A single rule could be:

<PasswordToken id="checkPassword">

<isEqual result="true">password</isEqual>

</PasswordToken>

A name (PasswordToken) of an entry specifies the used token. The id is to describe a rule

for a human reader. The attribute “password” takes a “password” property of a user from the

database. A “isEqual” tag means: The result of a comparison of the property with an entered

value has to be “true”. If the result is false a login process is aborted.

After registration in the user management system every application gets assigned a de-

fault rule-set. Administrators can modify this rule-set according to their needs. The default

rules are:

<?xml version="1.0" encoding="UTF-8"?>

<Authentication>



</PasswordToken>

<DateToken id="checkEnabled">

<isLower result="true">begin</isLower>


</DateToken>

<DateToken id="checkExpired">

<isGreater result="true">end</isGreater>

</DateToken>

</Authentication>

The first token checks the entered passwords of users. Only if the comparison returns a

positive result, the next token is processed. Furthermore every account is characterized by a

begin and end date. A DateToken is used to check one if these dates. The second rule in the

example checks if the begin date has a lower value than the actual time. Finally this login

process ends with a comparison of the expire date of an account. All tokens are successfully

processed if an account will expire in a future date.

4.3 The database model

The developed database model has to store all required information about users, groups, re-

sources, ACLs, and other administration related data. This authentication and authorization

system is using different data for each login process and therefore special passwords and

other data is used depending of a clients operating system during a login process. LDAP

servers need other data for Unix/Linux users like a login shell than a Samba server for Mi-

crosoft© Windows accounts.

The database model is separated into seven parts based on their logic functions illustrated

in figure 4.3:

• institutes (dark purple)

• users (light red)

• access management (green)

• group management (light blue)

• properties (light green)

• applications (pink)

• logging (light orange)


Figure 4.3:The developed database schema overview. Color-code: institutes (dark purple),users (light red), access management (green), group management (light blue),properties (light green), applications (pink), and logging (light orange).


4.4 The administration web interface

A web-application has been developed to provide a tool to administrate all applications,

users, resources, and access rights in a centralized database. This web interface is based on

the Jakarta Struts framework and Java ServerPages (JSP).

The interface was designed to provide administrators a quick overview of all users and

their corresponding access rights in corresponding applications. Security concerns leading

to two different kinds of administrators. The most powerful administrator is a special user

called “admin” which is only used for this web application. This user is able to get access to

all data stored in the database. He has the ability to change every user, group or application

specific information.

The second type of the administrator’s role can be applied to any user registered in an

application. These special users are able to manage all information of applications they are

administrators. All data of foreign applications are hidden due to security concerns.

An administrator of an application is greeted in the web interface with the page as shown

in figure 4.4.

Figure 4.4:Welcome page of the web interface

4.4.1 Application administration

Figure 4.5 shows how the global administrator can add new applications dynamically. There

is no restart of the user management system necessary after the definition of a new applica-

tion.

A random password (called application password) is generated for every registered ap-

plication. This password assures that no unauthorized request of a client connector interface


user is proceeded by the user management server. This random string is compared server-

sided to prove the client request as valid. Every method in the client connector interface

(see 4.8) is protected by this password.

Figure 4.5: Information about web-applications

4.4.2 User administration

This menu item accomplishes a powerful user management. The global administrator is able

to distribute application administration rights to normal users within this menu. Application

specific administration tasks are done by this normal users to disburden the global adminis-

trator.

Basic functions like create, show or edit users are available. New created accounts could

be added automatically to the applications of administrators. The enables users to use ac-

counts right after creation. No further actions of an administrator are necessary. Furthermore

all accounts can be enabled or disabled additionally for each registered application. Under

theset user passwordmenu a new password can be set for users, who have forgotten their

password.

4.4.3 Group administration

All basic add, remove, and edit functions are located under this menu item. An administrator

can add a user to groups and set all members of groups as application administrators. All


Figure 4.6:User administration

members of a selected group can also be disabled or removed. If an account has been already

used by a user, it cannot be deleted by removing the group. These users will only be disabled

for the selected application.

4.4.4 Resource administration

Resources represent the structure of the “content” an application provides to its users. Such

a content could be methods in Java classes or one or several combined web pages. ACLs are

bound to these resources to implement the access rights of users and groups. Basic operations

on these resources can be done with this page. It is possible to select add, edit and delete

actions.

4.4.5 Access control lists administration

ACLs are the individual access rights of users or groups to resources. Administrators are able

to arrange all access levels of their users and groups individually. Only information according

to the selected applications is shown. Other data is hidden for security and straightforward-

ness. Basic functions in the ACL menu are create, delete and edit.


Figure 4.7:Create a new resource

Figure 4.8:Binding an access control list to a user or group


4.5 OpenLDAP server with SQL backend

An OpenLDAP server in version 2.0.27 has been chosen to provide access for Unix/Linux

servers to this user management system. OpenLDAP is an open source implementation of

the Lightweight Directory Access Protocol (LDAP). This server supports parts of LDAP in

version 3. The software can be downloaded fromhttp://www.openldap.org .

All user data is stored in the relationalMySQLdatabase used in this framework. There-

fore a MySQL backend for an OpenLDAP server is used (see section 3.7.6). The OpenLDAP

server builds up its LDAP tree topology based on special MySQL database entries. The map-

ping of a relational table structure in the database to a tree topology is done by a LDAP-SQL

mapping described in section 3.7.6.

The MySQL and OpenLDAP server are not connected directly. An Open DataBase Con-

nectivity (ODBC) tier is located between both servers. An additional tier between this two

systems enables developers to choose another database vendor without modifying the con-

figuration of an OpenLDAP server.

The configuration of the ODBC driver and OpenLDAP server is shown in section 5.

4.6 Samba server configuration

The Samba2 server in version 3.0 is equipped with a SQL-password backend. This feature

enables the Samba server to store user data directly in the centralMySQLdatabase.

The SQL-password module is enabled in the main configuration file of a Samba server.

The following compilation flag enables the MySQL support:

./configure --with-expsam

A Samba server must be configured as a Public Domain Controller (PDC) to build up a

Microsoft© Windows domain. The basic steps to configure a Windows domain are:

1. Server and network settings

2. Security settings

3. Roaming profiles configuration

4. Public shares configuration

2http://www.samba.org/

http://www.openldap.org

http://www.samba.org/


5. Netlogon setup

6. User and machine accounts

7. Configuration of all clients

Domain logons are enabled under theglobal andnetlogonsections of a Samba configu-

ration file.

[global]

domain logons=yes

encrypt passwords=yes

workgroup=genome

[netlogon]

path=/home/netlogon

logon script=logon.bat

read only =yes

write list =@admins

These system policies enable Windows users to authenticate against a PDC and get their

profiles from the Samba server. Theglobal section enables domain logons and anetlogon

directive specifies the path of login scripts for all users (see section 3.6.3).

4.7 LDAP client configuration

An LDAP client is used to get user information for a Unix/Linux Portable Operating Sys-

tem for unIX (POSIX) account from an LDAP server. An LDAP client is activated in an

Unix/Linux system in the/etc/nsswitch file. In this file the succession of getting user

data is configured.

The/etc/nsswitch file has to look like this:

passwd: ldap files

shadow: ldap files

group: ldap files


This example denotes: Get login data first from an LDAP server. If a user cannot be

authenticated by the LDAP server use the local/etc/shadow file.

At a client workstation an LDAP connection is configured by the/etc/ldap.conf

configuration file. The IP address of the authentication server and its port number is con-

figured here. Also very important is the selected base entry (DN) of the LDAP tree (see

section 3.7.1). A system administrator must set the base root of its users.

It is possible to encrypt a connection to an LDAP server with Transport Layer Security

(TLS) and Simple Authentication and Security Layer (SASL) protocols. [35]

4.8 Client connector software

The client connector interface has been developed to enable applications to get access over a

logical interface to this authentication and authorization system. Thus applications does not

have to store information about its users, groups, resources and ACLs in its own databases

anymore.

4.8.1 Supported protocols

A connection can be established using one of the following four protocols.

HTTP: The HyperText Transfer Protocol (HTTP) is the usual protocol used by web

browsers to get information from web servers. HTTP transfers data as clear text in a

request/response technology. It is not burdened with an encryption layer. This speeds

up the connection, but the security to transmit sensitive data is not given.

HTTPS: A HyperText Transfer Protocol over SSL (HTTPS) is a HTTP with an additional

encryption layer. This enables secure connections between server and client. A server

needs a valid certificate (CA) to get connected. This CA has to be imported by a client

application (see section 5) to establish a secure connection. HTTPS uses a public key

encryption technology described in section 3.8.4.

SOAP/RMI: This interface enables applications to get a connection over an operating sys-

tem independent protocol. SOAP transfers XML messages over HTTP and enables

developers to establish standardized connections to the user management system.


RMI: The Remote Method Invocation (RMI) technology enables developers to get access

to the business logic located on the JBoss application server. This reduces the execu-

tion time of requests to the developed user management system.

A client application can use the protocol which fits best for needed purposes. E.g. if a

developer needs a secure protocol the HTTP over SSL (HTTPS) can be used (see [20]).

4.8.2 Client connector functionality

The client connector provides all functions required for an autonomous administration of

users, groups and according access rights of an application. All method invocations to the

server are secured by server generated id’s and additionally some administration methods are

secured by passwords. Unauthorized requests will not be processed by the user management

server. Only registered applications get access to their corresponding information.

4.8.3 Client connector configuration

The configuration of a client connector is handled by a simple property file. This file can be

adopted by a developer to meet the required needs. All necessary information for a connec-

tion to the user management server is found in this configuration file (see section 5).

Protocol: An administrator can select a protocol which will be used to establish a connec-

tion to the user management server. Possible protocols are:

1. HTTP

2. HTTPS

3. RMI

4. SOAP

Proxy: If the administrator of a local network does not allow direct connections to the

Internet, the application administrator can specify a proxy, to connect to the user man-

agement system.

Example:

proxy url=10.0.1.2

proxy port=3128

HTTP: The Uniform Resource Locator (URL) declares the Internet address of the user

management system. The address can be specified as a hostname or as a Internet


Protocol (IP) number. Additionally to the address a port number has to be assigned.

Example: httpurl=10.2.0.6, httpport=15080

HTTPS: This configuration option indicates the address and port of the web server with

SSL support. Additionally to the location of the certificate the URL and portnumber

of the server has to be specified.

Example:

httpsurl=taranis

httpsport=16443

keystorefile=/home/username/.keystore

RMI: This user management allows to connect directly to the business logic of the appli-

cation server. The RMI option specified the Internet address of the JBoss server.

Example:

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

java.naming.provider.url=10.2.0.60:15099

java.naming.factory.url.pkgs=org.jboss.naming.org.jnp.interfaces

SOAP: The URL and port number of the SOAP receiver is specified in this option.

Example:

soapurl=10.2.0.60

soapport=15080

Taglibs: Thecustom tags(see section 3.4.2) are configured in the client configuration file.

This data is used to forward an unauthorized user to the login page to initiate a new

authentication process.

Login page: If a user is not logged into the system and thecheckLogintag finds no

valid user value object in the browser context or the user is not permitted to log

into the application, the system guides the user to this specified page.

Example:

login page=/jsps/admin/login.jsp

Error page: If the user has no permission to a part of a jsp page, the tag can lead the

user to this given error page.

Example:

login error=/loginerror.html

error page=/loginerror.html


4.8.4 Client connector security

The user management system provides an easy and efficient way to protect all requests to the

server. Each client web-application gets its own unique password. This secret string must

be sent to the server to prove the identity of the client. Only if the transmitted password is

correct the request is proceeded by the server.

4.8.5 Client authorization

The developed system uses custom tag libraries (see section 3.4.2) to grant or deny access to

parts of web pages. This technology enables web developers to grant access to web pages ac-

cording to the access rights of users. The developed custom tag is calledhasPermission .

An example of ahasPermission tag:

<permission:hasPermission resourceKey="plates"

accessLevel="R">

.

.

Here is the protected part of the webpage. This

body is only accessible to users with proper

access rights (here right ‘‘R’’ to resource

‘‘plates’’).

Other user skip this part in a JSP.

.

</permission:hasPermission>

Another taglib has been developed to guarantee that a user has logged in before success-

fully. This tag is calledcheckLogin . Before processing a web page this tag connects to

the user management server and controls the unique id (see figure 4.2) of a user. If a visi-

tor of the web page is not logged in, he will be forwarded to a specified login page of the

corresponding application. [12]

Chapter 5

Discussion

The main goal of this thesis was to develop an authorization and authentication system which

consolidates web-applications, Windows, and Unix/Linux accounts into one combined sys-

tem. All members of the BIG should use only one account for all purposes. Only a single

username and password has to be remembered by each user. Furthermore an administrator

of the heterogenous network of the BIG should be able to administer all users in a fast and

comfortable way.

An evaluation of various existing user management frameworks has shown that no open

source system satisfied our requirements. The best starting position provided the OpenSym-

phony project. It was cardinally designed to provide an authentication and authorization

system for web-based applications.

In order to allow the integration of the Microsoft© Windows domain and various

Unix/Linux servers many adaptations in the database model and the code structure had to

be conducted to provide special information required by operating system specific authenti-

cation processes. These adaptions could be added with maintainable effort due to the fact of

the free available source code and well designed modular structure of OpenSymphony. This

additional functionality has been implemented without violating the primarily structure.

Beside all benefits provided by the original OpenSymphony project the insufficient doc-

umentation of the source code must be mentioned. But due to the fact of the clean modular

framework structure and complied coding guidelines the vocational adjustment period was

reasonable and thus a good basis for this thesis. The developed user management system for

molecular biology databases satisfies all requirements. Every member of the BIG is issued a

single account from the administrator. This gives users the ability to login into all worksta-

tions and servers as well as all web-applications they are authorized with the same account.

A user can be tagged with the rights of an application administrator. This enables him to

manage users, groups, resources, and the according access rights of this application.

54

CHAPTER 5. DISCUSSION 55

Additionally there is a global administrator who is able to register new applications and

their corresponding administrators, and to manage all Unix/Linux and Windows accounts.

All administrative tasks are accomplished by means of the developed, easy to use, and ef-

ficient web interface. During the web interface development process great importance has

been attached to security concerns. Application administrators get only access to data of

their corresponding users, groups, resources and according access rights. Other informa-

tion is hidden to them and only accessible by the global administrator. All applications are

logically separated due to security concerns. The web interface is connected to the under-

lying application server which contains the modified business logic of the OpenSymphony

project. All components of the user management logic are represented by Enterprise Jav-

aBeans (EJBs). These EJBs control login processes initiated by other client applications

and validate authentication attempts of users. All information which are required during

a login process are stored in the central MySQL database. Other web based applications

establish a connection to the user management system with the developed client connector

interface. This connector interface provides all necessary methods to allow applications to

manage their users, groups, resources and according access rights autonomously within their

developed application user-interface.

Windows and Unix/Linux operating systems are using the Samba and OpenLDAP servers

to validate login attempts. These servers are using only standardized and well established

protocols to connect client and server. Therefore no modifications have to be applied to

Windows workstations or Unix/Linux servers.

All requests of the client connector, Samba, and OpenLDAP server are handled by one

user management system. A centralized systems does not have only advantages it also in-

volves the problem of a single point of failure. A failure of this central system will lead to no

authentication validations of users in all registered systems. In future work a fail-over solu-

tion would improve the availability of the system significantly. Additionally for future work

firewall rules could be integrated into the user management system. Such a feature would

allow the global administrator to configure a firewall according to individual user privileges.

This would increase security concerns by fine grained access rights to the Internet.

This framework consolidates all user management systems used in the Bioinformatics

Group into one central system. Furthermore all administration tasks can be accomplished

by a clearly arranged and intelligible web interface under retention of all security concerns.

Additionally arbitrary applications are able to connect to the framework by an operating

system independent, secure and configurable client connector interface. Many state of the

art technologies are used to assemble a very flexible, secure, and powerful authentication

and authorized system. All this features assemble a framework which is indispensable for an

efficient user management system.

Bibliography

[1] Rahim Adatia.Professional EJB. Wrox Press Ltd, 2001.

[2] Jeremy Allison. sambapasswd user manaual, October 1998.http://optics.ph.

unimelb.edu.au/help/samba/smbpasswd.5.html .

[3] [email protected] Andrew G. Morgan. The Linux-PAM System Administra-

tors Guide, 06 2002. http://www.kernel.org/pub/linux/libs/pam/

Linux-PAM-html/pam.html#toc4 .

[4] Berhand Bablok. Trennkost - Die JSP Standard Taglib Library trennt Code und Darstel-

lung. Linux Magazin, pages 94–97, 05 2003.

[5] Hans Bergsten.JavaServer Pages. O’Reilly, second edition, 2002.

[6] Adam Bien. J2EE Patterns, Teil 3 Patterns der Prasentationsschicht.Javamagazin,

pages 52–58, 01 2003.

[7] Mike Cannon-Brookes. Plugable providers. http://wiki.opensymphony.com/osaccess/.

[8] Chuck Cavaness.Programming Jakarat Struts. O’Reilly, 2002.

[9] Microsoft Corporation. Types of Logon, 2002.http://www.microsoft.

com/technet/treeview/default.asp/technet/prodtechnol/

winxppro/reskit/prdp_log_ejbm.asp .

[10] Refsnes Data. Soap tutorial, 2003.http://www.w3schools.com/soap .

[11] Michael Donnelly. An Introduction to LDAP, April 2000.http://ldapman.org/

articles/intro_to_ldap.html .

[12] Michael Enderle. Tursteher - LDAP Zugriff mit Java JNDI.IX, 11:138–140, November

2003.

[13] Don Box et al. Simple Object Access Protocol (soap) 1.1, May 2000.http://www.

w3.org/TR/SOAP/ .

56

http://optics.ph.unimelb.edu.au/help/samba/smbpasswd.5.html

http://optics.ph.unimelb.edu.au/help/samba/smbpasswd.5.html

http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html#toc4

http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html#toc4

http://www.microsoft.com/technet/treeview/default.asp/technet/prodtechnol/winxppro/reskit/prdp_log_ejbm.asp



http://www.w3schools.com/soap

http://ldapman.org/articles/intro_to_ldap.html

http://ldapman.org/articles/intro_to_ldap.html

http://www.w3.org/TR/SOAP/

http://www.w3.org/TR/SOAP/

BIBLIOGRAPHY 57

[14] Erich Gamms et al.Entwurfsmuster. addision, 1996.

[15] Nick Gorham. unixODBC, 2003.http://www.unixodbc.org/ .

[16] The Open Group. Developing a Data View. 2000.http://www.opengroup.

org/togaf/p4/views/vus_data.htm .

[17] Kevin Hakman. E-Commerce Tutorial Lesson 3, 2003. http://

hotwired.lycos.com/webmonkey/99/04/index2a_page5.html?

tw=e-business .

[18] Sebastian Hetze.Anwender Linux Handbuch, Leitfaden fuer die Systemverwaltung.

LunetIX Softfair, Berlin, 7. edition, 1997.

[19] HyperWave.Access Rights in Hyperwave, 1997.http://wave.xray.mpe.mpg.

de/tools/hyperwave/user_hb/user05.htm .

[20] Jamie Jaworski.Secure Your Sockets with JSSE, 03 2001.http://www.onjava.

com/pub/a/onjava/2001/05/03/java_security.html .

[21] Volker Lendecke. Samba 3.0.Linux Magazin, pages 24–30, 09 2003.

[22] ArticSoft Limited. Introduction to Public Key Infrastructure, 02 2003.

[23] Marcel May. Zeitsaulen - Struts in der Praxis.Javamagazin, pages 77–85, 01 2003.

[24] Sun Microsystems. Java remote method invocation (rmi), 2003.http://java.

sun.com/products/jdk/rmi .

[25] Richard Monson-Haefel. Message-Driven Beans, 2001.http://www.onjava.

com/pub/a/onjava/excerpt/ejb3_ch13/?page=5 .

[26] Richard Monson-Haefel.Enterprise JavaBeans. O’Reilly, second edition, 2002.

[27] Openldap.http://www.openldap.org/ .

[28] Lars Pind. LDAP Introduction, May 2000. http://www.pinds.com/

software/ldap-in-general .

[29] R. Rivest. The MD4 Message-Digest Algorithm, April 1992.http://www.faqs.

org/rfcs/rfc1320.html .

[30] R. Rivest. The MD5 Message-Digest Algorithm. Technical report, MIT Laboratory for

Computer Science, 1992.

http://www.unixodbc.org/

http://www.opengroup.org/togaf/p4/views/vus_data.htm

http://www.opengroup.org/togaf/p4/views/vus_data.htm

http://hotwired.lycos.com/webmonkey/99/04/index2a_page5.html?tw=e-business



http://wave.xray.mpe.mpg.de/tools/hyperwave/user_hb/user05.htm

http://wave.xray.mpe.mpg.de/tools/hyperwave/user_hb/user05.htm

http://www.onjava.com/pub/a/onjava/2001/05/03/java_security.html

http://www.onjava.com/pub/a/onjava/2001/05/03/java_security.html

http://java.sun.com/products/jdk/rmi

http://java.sun.com/products/jdk/rmi

http://www.onjava.com/pub/a/onjava/excerpt/ejb3_ch13/?page=5

http://www.onjava.com/pub/a/onjava/excerpt/ejb3_ch13/?page=5

http://www.openldap.org/

http://www.pinds.com/software/ldap-in-general

http://www.pinds.com/software/ldap-in-general



[31] Andreas Roeschies. Blocke und Nachrichten - das SMB-Protocol von innen.Linux

Magazin, pages 30–33, 02 2003.

[32] Dr. Bernhard Rohrig. Einlasskontrolle - Benutzerverwaltung und Authentifizierung

unter Samba.Linux Magazin, pages 34–37, 02 2003.

[33] Paul Russel. Passwords That Don’t Suck.Linux Magazine, December 1999.

[34] Tim Schurmann. Sprachen selbst gemixt - Einfuhrung in XML.Linux Magazin, 01:42–

46, 2002.

[35] Volker Schwaberow. Pflegekrafte - LDAP Clients im Vergleich.Linux Magazin, pages

68–73, 11 2002.

[36] Richard Sharpe. Just what is SMB?, October 2002.http://samba.anu.edu.

au/cifs/docs/what-is-smb.html .

[37] Allen G. Taylor. Data definition and management, June 1996.http://www.

computerbits.com/archive/1996/0600/sql2.html .

[38] Microsoft TechNet. Default security settings, 2003.https://www.microsoft.

com/technet .

[39] Microsoft TechNet. User accounts overview, 2003.https://www.microsoft.

com/technet/ .

58

http://samba.anu.edu.au/cifs/docs/what-is-smb.html

http://samba.anu.edu.au/cifs/docs/what-is-smb.html

http://www.computerbits.com/archive/1996/0600/sql2.html

http://www.computerbits.com/archive/1996/0600/sql2.html

https://www.microsoft.com/technet

https://www.microsoft.com/technet

https://www.microsoft.com/technet/

https://www.microsoft.com/technet/

Appendix

Samba server configuration

A Samba Server 3.0 is used to assemble a Primary Domain Controller (PDC). The MySQL

support is enbaled in the global section of the configuration file.

smb.conf

[global]

netbios name = FOOBAR

workgroup = TESTGROUP

security = domain

domain logons = yes

domain master = yes

passdb backend

= plugin:/usr/local/samba/lib/pdb_mysql.so:mysql

mysql:mysql host = rhonwyn

mysql:mysql user = samba

mysql:mysql password = ambas

mysql:mysql database = samba

MySQL password backend

This backend is still under development (October 2003). The configuration information from

thesmb.conffile is ignored. The password backend plug-in is using its default values from

the source code.

To set the correct values, the filesamba-3.0/source/passdb/pdbmysql.chas to be config-

ured.

#define CONFIG_HOST_DEFAULT "localhost"

59

#define CONFIG_USER_DEFAULT "samba"

#define CONFIG_PASS_DEFAULT "password"

#define CONFIG_PORT_DEFAULT "3306"

#define CONFIG_DB_DEFAULT "samba"

Tomcat SSL certification

Generate a certificate

The first action is to generate a key for the SSL supported server. The alias is the user who

is running the server in the operation system. A self generated certificate expires after six

months. [20]

keytool -v -genkey -alias dieter -keyalg "RSA"

What is your first and last name?

[Unknown]: servername

What is the name of your organizational unit?

[Unknown]: Software Development

What is the name of your organization?

[Unknown]: Toolery.com

What is the name of your City or Locality?

[Unknown]: Chula Vista

What is the name of your State or Province?

[Unknown]: CA

What is the two-letter country code for this unit?

[Unknown]: US

Is <CN=enpower, OU=Software Development,

O=Toolery.com, L=Chula Vista, ST=CA, C=US> correct?

[no]: y

Export certificate

After generating the certificate, it should be exported to a file. This file must be published

on the home page of the user management system. The client which want to use the HTTPS

(see section 3.8.4) protocol has to import this generated certificate [20].

keytool -export -alias dieter -file osolemirnix.jer

60

Enter keystore password: changeit

Certificate stored in file <server.cer>

Import certification

keytool -import -keystore jssecacerts -alias jamie

-file server.cer

Enter keystore password: changeit

Trust this certificate? [no]: y

Certificate was added to keystore

Finally

Finally, copy jssecacerts to thelib/security subdirectory of the java.home directory.

(On the client machine.)

LDAP server configuration

The configuration file for the OpenLDAP server isslapd.conf.

include /usr/share/openldap/schema/core.schema

include /usr/share/openldap/schema/cosine.schema

include /usr/share/openldap/schema/corba.schema

include /usr/share/openldap/schema/inetorgperson.schema

include /usr/share/openldap/schema/java.schema

include /usr/share/openldap/schema/krb5-kdc.schema

include /usr/share/openldap/schema/misc.schema

include /usr/share/openldap/schema/nis.schema

include /usr/share/openldap/schema/openldap.schema

include /usr/share/openldap/schema/samba.schema

##################################################

# sql database definitions

##################################################

database sql

dbname sql

dbuser root

61

dbpasswd root

suffix "dc=genome,dc=at"

rootdn "cn=Manager,dc=genome,dc=at"

insentry_query "INSERT INTO ldap_entries

(dn,oc_map_id,parent,keyval) VALUES

rootpw secret

index objectClass,uid,rid,uidNumber,gidNumber,memberUid,eq

index cn,mail,surname,givenname,eq,subinitial

loglevel 5

# Basic ACL

access to attr=userPassword

by self write

by anonymous auth

by dn="uid=root,ou=People,dc=genome,dc=at" write

by * none

access to *

by dn="uid=root,ou=People,dc=genome,dc=at" write

by * read

LDAP client configuration

The configuration file for a Unix/Linux client isldap.conf.

# Your LDAP server. Must be resolvable without using LDAP.

host 10.2.0.60

# The distinguished name of the search base.

base OU=PEOPLE,DC=GENOME,DC=AT

# The distinguished name to bind to the server with.

# Optional: default is to bind anonymously.

binddn cn=Manager,DC=GENOME,DC=AT

# The credentials to bind with.

# Optional: default is no credential.

bindpw secret

# The distinguished name to bind to the server with

62

# if the effective user ID is root. Password is

# stored in /etc/ldap.secret (mode 600)

rootbinddn cn=Manager,DC=GENOME,DC=AT

# The port.

# Optional: default is 389.

port 389

# The search scope.

#scope sub

scope one

#scope base

# Filter to AND with uid=%s

pam_filter objectclass=smabaaccount

# The user ID attribute (defaults to uid)

pam_login_attribute uid

# RFC2307bis naming contexts

# Syntax:

# nss_base_XXX base?scope?filter

# where scope is {base,one,sub}

# and filter is a filter to be &’d with the

# default filter.

# You can omit the suffix eg:

# nss_base_passwd ou=People,

# to append the default base DN but this

# may incur a small performance impact.

nss_base_passwd OU=PEOPLE,DC=GENOME,DC=AT?one

nss_base_shadow OU+PEOPLE,DC=GENOME,DC=AT?one

ssl no

pam_password md5

Unix/Linux client configuration

The configuration file to enable LDAP supported authentication for a Unix/Linux server is

/etc/nsswitch.conf. T0he first entry in this file has to be changed to:

passwd: ldap files

63

shadow: ldap files

group: ldap files

Client connector interface configuration

The client connector interface is configured by theUserManagement.properties

config file. Here all information about the used protocol is specified. Additionally a proxy

server can be used by the client to connect to the server.

############################

# select your Protocol #

# HTTP or #

# HTTPS or #

# EJB/RMI or #

# SOAP #

protocol=HTTP

############################

##### HTTP Protocol ########

http_url=10.2.0.60

http_port=15080

##### HTTP Protocol ########

##### use proxy yes/no #####

#proxy=on

#proxy=off

#proxy_host=none

#proxy_port=none

#proxy_username=none

#proxy_password=none

##### use proxy yes/no #####

##### HTTPS Protocol #######

https_url=osolemirnix

https_port=15443

keystorefile=/home/dieter/.keystore

##### HTTPS Protocol #######

64

##### EJB/RMI protocol #####

java.naming.factory.initial\\

=org.jnp.interfaces.NamingContextFactory

java.naming.provider.url\\

=10.2.0.60:15099

java.naming.factory.url.pkgs\\

=org.jboss.naming.org.jnp.interfaces

##### EJB Protocol #########

##### define Error-Sites for Taglibs #####

login_page=/jsps/login.jsp

login_error=/loginerror.html

error_page=/loginerror.html

##### define Error-Sites for Taglibs #####

Authentication configuration

Example of a config file for the authentication process of an application. The tokens are

loaded dynamically by the system. Every new application gets three default rules assigned:

<?xml version="1.0" encoding="UTF-8"?>

<Authentication>



</PasswordToken>

<DateToken id="checkEnabled">

<isLower result="true">startdate</isLower>

</DateToken>

<DateToken id="checkExpired">

<isGreater result="true">expiredate</isGreater>

</DateToken>

</Authentication>

unixODBC configuration

The odbc.ini file

65

[sql]

Description = sql

Driver = sql

Server = localhost

Port = 3306

User = database user name

Password = password

Socket =

Database = sql

The odbcinst.ini file

[sql]

Description = mysql database connector

Driver = /usr/local/unixODBC/lib/libmyodbc.so

Setup = /usr/local/unixODBC/lib/libodbcmyS.so

FileUsage = 1

CPTimeout =

CPReuse =

OpenLDAP server configuration

include /usr/share/openldap/schema/core.schema

include /usr/share/openldap/schema/cosine.schema

include /usr/share/openldap/schema/corba.schema

include /usr/share/openldap/schema/inetorgperson.schema

include /usr/share/openldap/schema/java.schema

include /usr/share/openldap/schema/krb5-kdc.schema

include /usr/share/openldap/schema/kerberosobject.schema

include /usr/share/openldap/schema/misc.schema

include /usr/share/openldap/schema/nis.schema

include /usr/share/openldap/schema/openldap.schema

database sql

dbname sql

BIBLIOGRAPHY 67

dbuser root

dbpasswd passwd

suffix "dc=genome,dc=at"

rootdn "cn=Manager,dc=genome,dc=at"

rootpw secret

The database and dbname are not the name of the database in the MySQL DBMS. It is

the name of the ODBC entry.

Documents

Dieter Zeller Design and development of a user management ...genome.tugraz.at/Theses/Zeller2003.pdf · for molecular biology database systems Master ... Binding an access control