Novell is now a part of Micro Focus

One eGovernment: Bringing Governments to the Net

Articles and Tips: article

Jeroen de Beer
Consultant
NICS Consulting
Jeroen.debeer@nics.nl

Raymon Epping
Consultant
Novell, Inc.
Repping@novell.com

Rob van Diermen
Consultant
Novell, Inc.
Rvdiermen@novell.com

01 Apr 2002


With the emergence of the World Wide Web, governmental organizations have recognized a great opportunity to enhance communication with their citizens. However, governmental concerns entering the Internet space face different challenges than commercial companies face. This AppNote provides a case study on how governments can use Novell's Net solutions to overcome these challenges and fully leverage the real value of the Net.


Topics

eBusiness, eGovernment, DirXML, iChain, LDAP, security, Web application development

Products

DirXML, Novell iChain

Audience

network integrators, consultants, developers

Level

intermediate

Prerequisite Skills

familiarity with Web applications and security

Operating System

n/a

Tools

none

Sample Code

no

Introducing the "City Somewhere" Project

City Somewhere wants to improve its relationship with citizens and other organisations with the help of Internet technology. At the same time, it wants to reduce costs and improve efficiency. City Somewhere has 900,000 citizens. The services are divided into twelve departments, of which three are interested in starting an eGovernment project. Each of these departments has deployed specific information systems tailored to their own business processes:

  • Citizen Administration handles birth certificates. It uses an IBM AS/400 running DB2 to maintain all citizen information such as name, parents' names, date of birth, place of birth, social security number, and so on.

  • The Department of Finance (DOF) works with real estate property taxes. It uses an Oracle database on Windows 2000 to store information about all real estate objects and their owners. An owner does not need to be a citizen of the city; the owner could live in another city or could be a company. In either case, the owner would be unknown at Citizen Administration.

  • The Department of Environment Protection (DEP) handles water and sewer bills. It uses a Sybase Database running on Unix to maintain the homeowners/ users, the amount of water used, and the number of people living in the house.

The overall business goals of this eGovernment project are:

  • To provide personalized information to citizens and other stakeholders through Web technology

  • To assign users only one username and password to all the information they are allowed to access, regardless of the existing back-end systems

  • To create a new infrastructure that is flexible enough to support other departments in the future

  • To not replace existing systems if it isn't necessary to achieve the business goals (in other words, "If it ain't broke, don't fix it.")

The business goals for the Citizen Administration department are:

  • To allow citizens to request a birth certificate and pay for it electronically

  • To enable other departments and organisations to "look" directly into the CA database and see information that is relevant to them

The business goals for the Department of Finance are:

  • To provide homeowners or renters access to tax reports and status of payments

  • To provide access to other organisations such as other departments or national government agencies

The business goals for the Department of Environment Protection are:

  • To provide citizens access to the water and sewer billing system

  • To provide citizens the option to pay their bills by credit card

In addition, the project team identified five overriding principles which would guide all aspects of the project:

  • Security

  • Ease of management

  • Use of Internet standards

  • Multi-platform

  • Flexibility

Challenge of eGovernment: DiVision of Activities

This section describes the biggest challenge faced by a governmental organization looking to make use of the Internet: division of activities. Government entities typically divide their activities for political, historical, or legal reasons, or for the sake of efficiency.

Political Reasons

Politicians live by the day, just like citizens. If the cry of the day is for a new organization or a new dataset/database, that will be asked from the existing organization. Because it is not always possible or practical to integrate these new activities and databases into existing organizations or infrastructures, whatever is needed to fulfill this desire will be built, bought, or hired on the shortest term possible. This tends to undermine standardization on how the activities are organized or which platforms are used. But that is the way most systems are implemented. Organizations must have the flexibility to quickly adapt.

Historical Reasons

Not all governmental activities start out as a big activities, but it is possible (and fairly common) for small activities to evolve into big ones. Sometimes a function begins in a small office of another department and ends up consuming a big part of that department. Because of the history of such an office, it is integrated with another department, especially on the information systems level, even if the activity is not in the nature of the other department. Trying to separate an office or integrate it into another department whose nature is more similar is very difficult.

Legal Reasons

Mostly due to privacy concerns, governments organize the information flow into certain areas and hold the organization responsible for the secrecy of the information. It is forbidden by law to share this information with other organizations (governmental or non-governmental). This way private information can't be used in a way that negatively impacts the citizens.

Efficiency Reasons

It is much more efficient and simple to train people or organizations to specialize in one activity than to train them on every single activity in government (if that is even possible). By organizing activities in separate organizations and information systems, governments can be more efficient and effective in the way they work.

Creating a Unified "Virtual Government"

The downside of these divisions of activity is obvious. If a citizen communicates with employees of two different government services, each could give a right answer according to the information available to their department, but it might be the wrong answer for the citizen. Yet citizens fully expect to receive right answers from a governmental entity, not what a departmental employee thinks is the right answer. Citizens don't consider the government as a divided organization. If they are talking to an employee of the government, they consider that person to "be" the government.

By creating one virtual office on the Internet and integrating this with the different back-offices and departments, an eGovernment project can provide the citizens an integrated view of their government (virtually One Government).

The "virtual government" (or government portal) can be achieved in various ways. For instance, it can be built by Web designers using a portal product to ease the process. Novell Portal Services is ideally suited for this; however, the details of building such a government portal are beyond the scope of this AppNote. For more information on Novell Portal Services, see the product Web page at http://www.novell.com/products/portal.

The High-Level Solution

One thing must be made clear: it is not practical for the users of a system to have different identities for different departments within an organization. Each citizen must have one userid and one password (or device such as a smart card), and must be able to see all of the information that pertains to that userid. The solution must be transparent to the citizens, even if that causes problems at the back-end level.

One central authentication is the first step to create One eGovernment. Authentication is the process by which users prove they are who they say they are. Authorization is the process of determining who can access what application and what data. Authorization is the biggest problem in this scenario. There are two possible solutions to this problem:

  • Centralize both authentication and authorization

  • Centralize authentication, decentralize authorization

Centralize Authentication and Authorization

In this model, the authorization would be integrated with the authentication and the back-end applications. Even if this were the ideal solution, it isn't practical (at least not for now) for a number of reasons.

First, how do you integrate dissimilar information systems and keep them synchronized? Of course, there are synchronization systems on the market, but the data model of most government organizations' databases is very complex. Most fields and records are connected to other. Changes at the field or record level, or to database schemas or structure could harm this model. You would need a very sophisticated system to adapt to such changes quickly. Integrating disparate systems into one is very difficult and would require a standard, which undermines the overriding principle of flexibility.

Second, who gets to decide who can access which information? In this model, people who manage the system would be responsible for authorizing users to access back-end information. This brings up the interesting question of ownership. A person cannot be held responsible for information if he or she doesn't handle the authorization. People who manage systems on a centralized basis won't have the knowledge of this information. How are they supposed to handle access with care if they don't understand it?

Centralize Authentication, Decentralize Authorization

In this model, the authentication is done at a central directory service that contains all the possible customers and government employees. The authorization information is stored in this same directory at a user, group, or "community" level. The back-end information systems can provide personalized content in the following ways:

  • Specific user information stored in the directory is sent to the Web application, which uses this to query the back-end systems

  • The Web application can make LDAP queries to the directory to get specific user information and use this to query the back-end systems

In this model, the boundaries between the different departments or organizations are respected and accepted because they are there for a good reason, but it still gives the citizen an experience of a virtual integration of the government. The only synchronization that is done is limited by placing only authorization attributes in the directory and keeping those synchronized.

The authentication/authorization process would generally proceed as follows:

  1. A user enters his credentials (for instance, userid and password) on the government portal page.

  2. The credentials are checked against the directory to see if they are a valid combination.

  3. The destination application and ID are checked to see if the user has rights to go to the destination.

  4. The authentication process checks to see if there is a profile stored in the directory regarding this user. If so, the profile is sent to the destination application.

  5. The authentication process checks to see if there is an authorization field for this application on the user record. If so, the authentication is sent to the destination application.

  6. The destination application receives the profile and authorization field(s) and requests the needed information using the authorization field from the back-end system.

  7. The information is provided to the user.

By using this model, the following advantages are achieved:

  • The boundaries between organizations are respected and accepted.

  • The only synchronization necessary is that of the authorization fields.

  • The owner of the information manages that information and decides who gets access to it. This places knowledge of information where it is needed.

  • No changes are necessary to the back-end systems.

  • Fast implementation is possible.

It is clear that the only practical solution at this time for providing One Government consists of a combination of the government portal and the Centralized Authentication, Decentralized Authorization model. The remainder of this AppNote will describe how to use Novell DirXML and iChain to build the supporting infrastructure for this One Government project.

The Role of DirXML

DirXML, one of Novell's Net solutions, is a product that can be used to keep directories or databases synchronized at the field or record level. DirXML is divided into two parts. The first part is the connector, which speaks the native language of the directory or application and the XML language. The second part is the DirXML engine that transports the XML documents between the systems and allows modification or translation with XSLT. These two parts make it possible to connect databases or directories with each other, using Novell eDirectory as a data hub.

Without DirXML, companies would have to write a connector for each database/ directory to connect with each other, as shown in Figure 1. This would necessitate writing a lot of connectors.

Without DirXML, you need a lot of connectors to talk between systems.

DirXML makes it possible to connect all databases/directory via a data hub and synchronize this information to other databases and directories, as shown in Figure 2.

With DirXML, eDirectory acts as a hub to synchronize data between systems.

Another major advantage of DirXML is the possibility of modifying fields, records and values while processing data from one directory/database to another. A good example is the format of the date field that is not always the same in all databases (mmddyyyy or ddmmyyyy or ddmmyy). With the use of XSLT, it is possible to change the format "on the fly" before importing or exporting this value. Another example is the creation of userids, passwords, and e-mail addresses from database values or generating this by the use of Java servlets.

Novell has already written several connectors to be used with DirXML. Examples include specialized drivers such as the Active Directory Driver, NT Domain driver, Exchange Driver, PeopleSoft driver, Lotus Notes driver, and SAP HR driver. General drivers includes the LDAP driver (to connect LDAP sources such as Netscape iPlanet, IBM Secureway, and others), the JDBC driver (to connect JDBC databases such as Oracle, SQL Server and DB2), and the Delimited Text driver that will import and export XML or CSV documents. Other connectors are being developed all the time. Those who want to write their own drivers can use the DirXML connector developer kit available for free from Novell's developer Web site at http://developer.novell.com.

DirXML in the One Government Model

This section highlights the differences between a "normal" driver and an "eGovernment" driver and explains how to handle them. The main differences lie in these areas:

  • Large number of users / small data synchronization

  • Different connectors

  • Authoritative data source at field level

  • Matching rules

  • Delete rule

  • Generating with Java

Large Number of Users / Small Data Synchronization. The government has all of its citizens as customers, which can easily be in the hundreds of thousands or even millions of users. On top of that, the government has to communicate with a lot of companies and other organizations. To keep this system manageable, the system itself must be as simple as possible. The only information that has to be in the directory are the authentication information (userid, password or SmartCard), profile information, match fields and back-end authorization information.

In the DirXML connector, there is only need for the matching and authorization information--the profile is optional. Keeping the connector as stripped as possible will make things simpler and allow you to easily manage performance. Due to performance issues, you must index the matching fields in the directory so they can be found quickly by the matching process.

Different Connectors. Normally DirXML is used for employee provisioning. For example, a user is created in a PeopleSoft database. DirXML synchronizes to eDirectory and creates an eDirectory user, with appropriate rights, based on properties delivered by PeopleSoft. After that, the user is synchronized to an Exchange directory where the user object gets its e-mail address. Then the user will be created in an Active Directory domain to get the rights to some applications. The user will be synchronized to an LDAP system for presence in an address book.

In an eGovernment system, you will most likely have back-end databases instead of directories, so you will use mainly the JDBC driver, the LDAP driver, and the Delimited Text driver. In rare cases when all else fails, you can write the connector yourself. Most specialized drivers have pre-configuration files; the generalized drivers mostly do not, so this has to be done manually. Because these drivers are more complicated than the specialized ones because of the configuration issues, they take longer to test and deploy.

Authoritative Data Source at Field Level. Because of the nature of government back-end databases, some of the fields in databases will be the same, while others won't be. The information used in one department won't necessarily be the same as in the second department, even if it should be. When building an eGovernment driver, two things are important: what authorization field is used for querying the back-end database, and what field is used to match the user. (The matching rules are explained in the next section.)

The authorization field has to be something the back-end system understands: for instance, the social security number. If an organization uses the social security number for authorization on the back-end, the back-end database must be 100% correct with the organization that manages these numbers. Mostly this is not the case, except of course for the organization that manages these numbers.

The best authorization fields to use are internal database numbers that are used by the organization. Because nobody knows (or cares) about this number, this field will always be correct for the back office database and if an organization wants to change this field, this can be done. If the organization would use a number that would also be used by other organization in the government directory it would be a much harder issue.

Every organization should be in control of their own authorization number to respect the organizational boundaries. Because they are in control, they are the only ones who control which users get access to what information.

Matching Rules. Matching rules are a key issue in an eGovernment DirXML driver. One value between two systems must be equal in order to associate the user record in the back-end database with the user record in the directory and keep them synchronized. For example, this could be either the social security number or a self-generated number.

There is no need to have one matching field for all back-end databases. You might have a configuration in which database 1 is matching on matching field 1, database 2 on matching field 2, and both database 3 and 4 on matching field 3. This gives enough flexibility to connect all databases without having to maintain one single field in all records. For those matching fields, there must be one Authoritative Data Source; otherwise, changes to this field would create some headaches. The two-way synchronization nature of DirXML makes it possible to keep the matching field synchronized in all back-end databases so that the association is never lost. The best matching fields are the ones which are used broadly within all connecting back-end databases and which are already in sync with each other.

Figure 3 shows what this system would look like when it is set up.

Process flow of the eGovernment project's DirXML system.

The process flow as illustrated in Figure 3 is described in the steps below.

  1. The DB2 database on the AS/400 creates an XML record with the following fields: Given Name, Last Name, Social Security Number, City Administration Number.

  2. The DirXML engine searches to find a match on Social Security Number but doesn't find one.

  3. The DirXML driver uses a stylesheet that calls one Java servlet: GeneratePassword.class.

  4. The class-file generates a random password.

  5. The DirXML engine builds a create-user file with the following values: JSmith (made up of first letter of given name and whole surname - if necessary a Java servlet can generate random userids), <random password>, John, Smith, 322-233-48483, 58533882.

  6. The DirXML engine sends this information to eDirectory to create the user. It builds the user and creates a DirXML association.

  7. The Oracle database of the tax department creates an XML record with the following fields: Social Security Number, Last Name, dofTaxAccount.

  8. The DirXML engine searches to find a match on the driver association, which fails. After that it tries on dofTaxAccount, which also fails. The last match is on Social Security Number and the engine finds KJones.

  9. KJones gets modified with the property dofTaxAccount with value 007554.

  10. The Sybase database of the water department creates an XML record with the following fields: dofTaxAccount, Last Name, Social Security Number.

  11. The DirXML engine searches to find a match on the driver association, which fails. It next searches on dofTaxAccount and finds JSmith. It creates only a DirXML association of the driver.

To sum up, DB2 uses Social Security Number as a match field and City Administration Number as the query mechanism to its own database. Oracle uses Social Security Number and/or dofTaxAccount as matching fields and dofTaxAccount as the query mechanism to its own database. The Sybase database of the water department uses dofTaxAccount and an optional Social Security Number (if no match is found on dofTaxAccount) to match the user, and uses the dofTaxAccount as the query mechanism to its own database.The water department has two sorts of customers: citizens and non-persons such as companies. Citizens have social security numbers, while non-persons do not. So the Social Security Number field should be optional in the DirXML driver. In the Sybase database, the only difference between persons and non-persons is the empty Social Security Number field. This field is also empty if a new citizen is added for which the water department doesn't yet know the Social Security Number. Because the Citizens database doesn't contain dofTaxaccount, it won't submit this value to eDirectory. If the water department is faster with its information than Citizen Administration and the tax department, problems could arise with the creation of the user. Let's look at an example where the water department wants to create a user and the Social Security Number is not filled in. When the Sybase database wants to create a user, it tries to match on dofTaxaccount, but doesn't find a match. It then tries to match on Social Security Number, but since this field is empty it doesn't find a match and a new user is created in eDirectory without the Social Security Number filled in. If the user is a citizen, it will end up having two userIDs: one created by the Sybase database and one later by the DB2 database. On the other hand, the Sybase or Oracle database could be creating a non-person, such as a company, that doesn't have a social security number. (The DB2 database is specialized for citizens; it doesn't contain any non-persons.)Besides the dofTaxAccount, the Sybase database doesn't contain any additional information that could be used to match to the other databases. With the use of a Java servlet and JDBC, the Oracle database-which in this example contains another table which isn't connected to the DirXML driver of the Oracle database (otherwise the user would have already been created by the Oracle driver)-can be queried for the existence of the dofTaxAccount and the Social Security Number that should be associated with that user. Of course, you can query a totally separate database system in another organization as long as it contains these two necessary fields. Then the social security number could be used to find the user. If the dofTaxAccount or social security number is not found, the driver assumes this is a new non-person and the user gets created.

If for whatever reason the user turns out to be a citizen after all and gets created from the DB2 database, a problem would arise. That's why the Oracle driver should always have two matching fields; if both are on different users, the following action must be taken. The userID created by the Sybase database should be deleted. The user created by the DB2 database should be modified to have the dofTaxAccount property and value. The Sybase DirXML association between the deleted user and the Sybase database must be transported to the new "good" user. Possibly the citizen should be notified that a mistake has occurred and that one of his userIDs has been eliminated. While this is a rare occurrence, these things can and will happen and must be accounted for. The extreme flexibility of DirXML is very handy to handle such situations.

Delete Rule. With employee provisioning, when a user leaves the organization the corresponding userID is removed from all databases. This is different in an eGovernment system because a citizen can be in some databases and not in others. It is possible that a citizen has to be removed from one back-end database because his presence is not relevant there anymore, but has to maintain entrance to other systems. A user deletion in a back-end database would lead to a remove association with the back-end database it is deleted from, while still existing in the other databases. Because the back-end database has no knowledge of whether the user exists in other databases, DirXML must query the directory to see if other associations exist. If not, the user is deleted; if so, the association is deleted. For every eGovernment system, there will be a need for one DirXML delete driver.

Of course, the create rule is special too. Only the first database will create the user; the other systems will have to match the user. In this case, a create will mostly be an associate event. DirXML will know if the user is already associated. If it is not, DirXML will try to match it with the matching rule. If it finds a match, it will associate; if not, it will create the user by passing the XML document to the create rule.

Generating with Java. With this kind of complex DirXML system, the use of Java servlets is very desirable to be as flexible as possible. Java servlets can be called from a stylesheet to perform special functions such as generating passwords or userIDs, or to perform LDAP/JDBC queries to the directory or other systems. Through servlets, hundreds of thousands of usernames and passwords can be generated or modified on the fly when creating the users.

The Role of iChain

iChain, another of Novell's Net solutions, provides an access and security management infrastructure that protects the network and safeguards sensitive eGovernment and identity data. iChain facilitates the eGovernment and remote access initiatives by providing secure authentication and access to portals, Web-based content, and Web applications. Figure 4 illustrates where iChain is positioned in the infrastructure.

Positioning of iChain in the system infrastructure.

In traditional solutions, each Web server and application has its own security mechanisms. With iChain you create a "central" security architecture between the firewall and the Web servers that manages authentication and authorization for all Web servers and applications. The security architecture uses eDirectory to store and retrieve security information.

Besides authentication and authorization, iChain provides the following core functions:

  • Robust security model with fine-graded access policies

  • Rapid development and integration of eGovernment applications

  • Web single sign-on capabilities

  • Scalability and performance

Simple iChain Architecture

A typical iChain infrastructure is made up of three parts:

  • Proxy Server

  • Authorization Server

  • Web and Application Servers

The Authorization Server is special version of Volera's Excelerator. It functions as a reverse proxy and uses the directory server for authentication. The Proxy Server is placed in front of the Web and Application servers. The end-user will only communicate with the Proxy Server, not directly to the Web servers. Figure 5 shows how these components work together.

Process flow in the iChain system.

The process flow shown in Figure 5 are detailed in the steps below.

  1. Employees, citizens, partners, or any Web-based clients access a URL via the iChain Proxy Server. Every request send by the browser to the Web Servers goes through the Proxy Server.

  2. The Proxy Server uses configuration information stored in eDirectory to determine if the URL is a protected resource. If the URL is protected, the server will ask for the user's authentication credentials. These credentials may take the form of a name and password, a digital certificate, a smart card, and so on. The credentials are compared against information stored in the user's object in eDirectory.

  3. The user sends a request to the public URL, and the request is forwarded to the particular Web Server. The Web Server's response is sent back to the browser. Static information is cached at the iChain Proxy Server. Future requests will be served from cache, which dramatically reduces the Web Server's workload.

  4. In this case, the user sends a request to a protected URL and the actual Web Server uses its own security mechanism-the user is forced to authenticate. Once the user is authenticated, the iChain Proxy server sends the user credentials (base64 encoded) to the Web Server in the authentication header of the HTTP request.

  5. The Web Server contains only static information and needs to communicate with back-end systems to retrieve dynamic data.

  6. Once authenticated, the iChain Proxy Server may inject attribute-value pairs into the HTTP headers as a query string so that Web applications can be customized for the user. The attribute value pair is derived from a pre-configured LDAP query; in this example, it is the social security number and the PostalCode (?sosec=322-233...&postalCode=6744MB). The Web Servers generate personalized content as a result of sending user credentials and/or additional attributes to the particular Web Server.

Multiple Web Servers can be serviced by one iChain Proxy Server (or, for fault tolerance, multiple servers can be clustered to service one or more Web servers). Accessing other resources or Web Servers does not require additional logins. The iChain Proxy Server remembers who the user is and allows access to any resource to which the user has been granted access.

The Authentication Server is a server running eDirectory. The schema for this tree is extended with special objects and properties to facilitate iChain. These special objects are the ACL rule and the iChain Service Object (ISO).

iChain supports different authentication methods such as Login ID / passwords, X.509 certificates, tokens, and smart cards. iChain eliminates the need to implement these on all back-end systems. This way there doesn't have to be an authentication method in every back-end system, possibly resulting in the need for more smart cards and so on. With Login ID / passwords, any LDAP field in the directory can be used for authentication.

The authorization process is enforced to ensure that users do not get access to any unauthorized data. The Authorization Services authorizes access requests based on rules stored as objects in eDirectory, leveraging the directory's hierarchy and inheritance mechanisms. "Public" access can be allowed with no authentication point.

Figure 6 shows how and when a user receives access to a Web resource in a given iChain configuration.

How access is granted in the iChain system.

An iChain accelerator is a configuration entity on the iChain server that maps an outside IP address and port to a Web site (IP address and port) on the inside. Each accelerator has the configuration option for authentication and what method is necessary to forward the users request to the Web Server. When a request from a client browser hits the accelerator and no authentication is required, the user is granted access to the resource. When authentication is enabled on the accelerator, the next level in the security model handles the request.

The second level in the security model is the protected resource. A protected resource is a URL allowing access-down to file level if required-for example, my.county.gov/website/webpage.html. Protected resources have a number of wildcard options ("*" and "?") that allow different levels of access. In addition to the URL, the protected resource can be configured as:

  • Public - no authentication is necessary to access the resource

  • Restricted - forces the user to authenticate with the methods defined at the accelerator. A user is granted access when he is authenticated.

  • Secure - forces the user to authenticate with the methods defined at the accelerator and the request is passed on to an ACLcheck.

ACLcheck is the third layer in the security model. Access is granted through the use of iChain access rule objects (Access Control Lists) stored in eDirectory. Each object can contain multiple URLs, allowing access down to file level if required.

As with protected resources, rules have a number of wildcard options that allow different levels of access. For example, an access rule containing "my.county.gov/*" will grant access to the entire Web site to anyone associated with this rule, while "my.county.gov/?" would grant access to the root Web directory only. Access rules can be assigned to containers, groups, and users. Each rule has an exception list so access could be granted to all users within an Organizational Unit except for certain specified users.

In the near future, iChain 2.1 is scheduled to be released with a new feature: Query-based ACLcheck. This feature will make it possible to restrict access to Web sites at the property or property value level. You can then set up the system so that only users who have the property dofTaxAccount will have access to the Web site. This will further enhance the flexibility of the authorization system because this property can be managed by DirXML from the back-end database. It will also give separate departments even more control over user access to their systems.

iChain comes with a few Java servlets for managing user information such as changing passwords and so on.

Single Sign-On to Web Resources. Single Sign-On is the ability to forward authentication information to a Web server in the HTTP authentication header. Using a feature called Object Level Access Control (OLAC), this Login ID and password may even be different from that which the user originally entered. Most important here is that it does not require any changes to the Web resource.

OLAC provides access control which lowers administration management. Each proxy or accelerator has one or more Web servers defined as protected resources within the iChain Service Object in eDirectory. For each protected resource, you can enter values in the "OLAC Attributed" field to define which values, if any, will be forwarded to the accelerated Web server.

In the case of single sign-on, two field names are available: ICHAIN_UID and ICHAIN_PWD. These parameters would replace the regular Authentication Header information from iChain, which is the distinguished name along with the specified attribute.

For example if you have an NT-based Web server that has Basic Authentication enabled, it would not understand the distinguished name normally presented by iChain. However, using OLAC, you can define the ICHAIN_UID to make an LDAP request for the common name (CN) of the user and pass this attribute to the NT server instead of the distinguished name. The NT server would then have a username it recognizes, and it would be able to process the authentication request.

Another option to provide single sign-on to Web applications is XML Form Fill and secret store. This feature stores user credentials in the directory for Web applications that use an HTML form for authentication (such as Novell's GroupWise WebAccess).

Figure 7 illustrates the iChain logic flow.

Logic flow in the iChain system.

The following description of the logic flow assumes the user is already authenticated and authorized to access the requested URL.

  1. The browser sends a request to iChain.

  2. iChain queries the LDAP server for the URLs the user is authorized to access.

  3. The LDAP server returns a list of the authorized URLs.

  4. iChain sends a request to the Web Server with the username and password base64-encoded in the HTTP header.

  5. The Web application queries the LDAP server for the user and/or group attributes.

  6. The LDAP server returns the attributes to the Web Server.

  7. Based on the attributes and application logic, the result is sent back to the iChain server.

  8. The iChain server passes the information back to the browser at the user's workstation.

iChain in the One Government Model

iChain doesn't have as many differences from normal implementations as DirXML has with it normal implementations counterparts, but still there are a few key issues to consider in the One Goverment model:

  • Authentication methods

  • Large number of accelerators, possibly local

  • Live data

  • Profiles

Authentication Methods. Governments are looking at more modern methods than passports for identifying people. Smart cards and biometric methods are especially attractive. This brings in an interesting point. People who are giving out passports these days aren't usually IT-minded. People who are giving out authentication information are mostly IT engineers, many of whom are hired from commercial organizations. But in the future these specialties will come together. This question doesn't have one answer; project teams must think this situation over and make the best possible decision.

Large Number of Accelerators, Possibly Local. Depending on how much departments are integrated in the iChain system, there may be numerous accelerators configured on the iChain Authorization Server. Some or all Web applications will be housed at the organizations hosting the data service. This makes designing a proper and safe iChain system fairly complex. Several questions have to be answered, such as:

  • Where will the Proxy Server(s) be placed and how will this affect the DMZ?

  • Where will the directory server(s) be placed and managed?

  • What about the availability of the Web applications themselves?

A sample configuration is shown in Figure 8. In this example, each department has its own iChain server for employees. Reasons for these additional iChain servers are:

  • To make internal workstations independent of the well-being of the city ring

  • To avoid unnecessary traffic over the city ring

  • To protect Web-based resources in the departmental DMZ from internal users

  • To provide Single Sign-On to all departmental Web sites and portals

Because iChain is a very flexible system, you could easily modify this example to conform to the needs of your organization, taking into consideration security, money, and other factors.

Example City Somewhere eGovernment infrastructure.

Live Data. Governments must not make mistakes. When entering the Internet arena, the communication between government and citizen has to be 100% accurate. The only real way to accomplish this is by working with live data from back-end databases. This brings up another interesting point: government employees must realize that every change they make on citizen records will be published on the Internet. Of course, this is more an organizational than a technical issue, but it needs to be mentioned. With live data, the biggest advantage would be that government employees and citizens use the same information at the same time, instead of the possible "old" information contained in plain old letters.

Profiles. With the use of OLAC, it is possible to sent profiles to the Web application. Profiles can be used to set up a Web page with different views for different communities. It is possible that some information in the back-end database is only relevant for companies. Instead of figuring this out at the back-end, iChain can send the profile "company" to the Web application and the Web application will build a special page for the company profile. It is possible that for some applications the user is a "company" while for others the user is a "citizen". By defining profiles per application, it is possible to make that distinction.

Another example is the possibility of letting users specify if they have broadband capability and storing the answer in the directory. The Web application can then deliver a full-featured page to the broadband user, while delivering a scaled-down page to the modem user.

Profiles can be filled on different places: in the back-end database by the employees, with DirXML using XSLT, in the directory itself by using the iChain servlets, or from the Web application with a form that is sent via LDAP to the directory.

Putting It All Together

As you have seen thus far, the Centralized Authentication/Decentralized Authorization model is made up of two parts. iChain handles the authentication process and delivers the needed authorization information to the backend application. DirXML makes the system work by providing the authentication information to the directory and keeping it synchronized. Figure 9 is an overview of the total process flow of this system.

If you review the business goals for the City Somewhere project, you can see that all goals are fulfilled by this solution. There is a personalized system for users, companies, and other organizations. No changes at the back-end level are needed. The flexibility to connect other systems/departments has been completely realized.

Because the authorization information is placed into the directory directly from the back-end database and the query mechanism uses this information to query the back-end database, authorization is done where it should be: at the department level.

Total process flow of the eGovernment system.

While creating this system, City Somewhere also built a system which can be used for remote government workers to access their Web applications, files, and e-mail. Even electronic voting by citizens could be easily achieved. City Somewhere is ready for the Internet Age.

Conclusion

This AppNote has described how governments can enter the Internet Age with one integrated system, while at the same time keeping their organizational and technical boundaries. The potential of the Internet can be leveraged to communicate in a more powerful and integrated manner, without the difficulties normally associated with an Internet presence. Novell's Net solutions provide an easy-to-implement framework on which governments can build their electronic relationships with their customers, wherever they are and whenever they desire to connect.

Several good AppNotes and other resources are available on the subject of DirXML and iChain. Here are some links for more information:

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates