See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/257354739

Intranet Portal Security

Conference Paper · September 2005

CITATION READS

1 507

4 authors, including:

Natalia G. Miloslavskaya Alexander Tolstoy

National Research Nuclear University MEPhI National Research Nuclear University MEPhI
166 PUBLICATIONS   151 CITATIONS    112 PUBLICATIONS   113 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Security Intelligence Centers View project

Security Intelligence Centers View project

All content following this page was uploaded by Natalia G. Miloslavskaya on 03 June 2014.

The user has requested enhancement of the downloaded file.

 INTRANET PORTAL SECURITY

Natalia Miloslavskaya, Alexander Tolstoy,

Denis Nikolaenko and Sergey Veligodskiy
Moscow Engineering Physics Institute (State University), Moscow, Russia
milmur@mephi.edu

ABSTRACT
The paper examines Intranet portal features. After that its logical structure is the following -
"vulnerabilities & threats -> security policies & security requirements -> secure portal model -> portal
design example". Known threats to separate portal resources and their potential users are reminded.
Implied requirements to Intranet portal security are elaborated. Reference model of a secure Intranet
portal is suggested. The MEPhI’s project “InfoWar” is quoted as the described model viability example.

KEYWORDS
Portal, Intranet portal, Web technologies, Information security

1. INTRODUCTION TO PORTALS
The next step of networks' evolution after LANs is a localized Internet of a particular
organization known as an Intranet. This "Search Driven World" [1] is intended to integrate
people, processes and information within an enterprise. Intranet as a corporate uniform
"information network" uses the Internet-based technologies within an organization to facilitate
communication and access to information. Common entry to the Intranet resources is a portal.
It provides a personalized single point of access to applications, content, people and processes
through one common user Web interface. As usual portals have no client software
dependencies beyond a Web browser.
Portals are divided into some classes according to their technical implementation and target
audiences. Well known from 1998 portal type is an Intranet (or corporate) portal. Businesses
are using it to implement a centralized point of access for information and services to customers,
employees and other businesses. Intranet portals provide storage, processing, analysis and
access control to the structured and not structured data used in internal and external business
processes. They accumulate data from diverse internal and external sources, provide access to
data by all users, present information in the format appropriate for each of them, provide
underlying services for such an applications as search, collaboration, workflow and security and
also guarantee performance and availability. Intranet portals solve a lot of the primary goals
facing IT departments: maintenance scalability and portability of corporate applications,
implementation principle of uniform administration and management point, Single Sign-on
support, reduction resources for infrastructure support etc. According to Shilakes and Tylman
[2] "Enterprise Information Portals are applications that enable companies to unlock internally
and externally stored information, and provide users a single gateway to personalized
information needed to make informed business decisions." They are: "... an amalgamation of
software applications that consolidate, manage, analyse and distribute information across and
outside of an enterprise (including Business Intelligence, Content Management, Data
Warehouse & Mart and Data Management applications)". Content Management Systems
process, filter and refine "unstructured" data and information, often restructure it and store it in
a corporate centralized/distributed repository. Business Intelligence tools access data and
information and through querying, reporting, on-line analytical processing. Data Mining and
Analytical Applications provide a view of information both presentable and significant to the
end user. Data Warehouses and Data Marts are integrated, time-variant, non-volatile collections
of data supporting DSS and EIS applications, and, in particular business intelligence tools and
processes. Data Management Systems perform extraction, transformation and loading, "clean
data, and facilitate scheduling, administration and metadata management for data warehouses
and data marts" [2]. As it can be seen even all the modern information and network
technologies are used for portal functioning support. Presence of some known, but unrepaired
vulnerabilities in them may be profited by different malefactors and thus affects general
information security of any portal implementation and ultimately any corporation viability.
2. VULNERABILITIES AND THREATS TO INTRANET PORTAL SECURITY
To be a smart business, companies must deploy a comprehensive and integrated framework of
information and collaborative solutions that work cohesively together to meet their users
requirements. For that purpose they must develop reliable security infrastructure to balance the
need for secure access management with the need for continuously available services based on
security clearance. A typical consumer self-service solution uses a single point of access to a
business through a Web-based Intranet portal. Consumers need to feel confident that portal
information and self-service features are secure. Naturally they need to trust that a portal
"owner" provides proper controls on personal information and transactions being carried out. In
turn information to/from portal users can be more effectively captured, audited and controlled.
The user logs on and is given access only to information that he/she is authorized to access. For
that purposes some notion of user roles or past history is usually supported. At the same time
portals have essentially simplified malefactors’ life. For example, if earlier it was possible to
limit an access to the certain applications at a network level with different passwords, with the
advent of the portal technologies this access is realized through a unique public point, controlled
at an application level. Hence, from the information security viewpoint a portal becomes the
"Enterprise Information Heart" which cardiac arrest leads to the significant losses. Mass users'
access, numerous known and meanwhile unrevealed vulnerabilities in the systems used and
software applied, incorrect configuring and portal architectures and other factors essentially
increase notorious threats to confidentiality, integrity and accessibility of portal resources.
Portals come in many shapes and sizes — and so do the problems associated with their security.
Generally, an Intranet portal is a classical Web application with a set of its typical security
problems. Various Web applications allow users-clients to gain access along the data channels
to a central resource — a Web server and via it to the others such as database servers. In
practice each of these components of the Web client-server architecture (servers, clients and
channels) are susceptible to very many old and modern security threats (executable because of
some vulnerabilities). For example one of unresolved is the problem of storage and transfer
user sessions identifiers (Session ID), used for authentication in a Web application. Today two
most widespread attacks on Session ID are a "cross-site scripting" attack (it allows abducting
Session ID from lawful users) and a "phishing" attack (it lures the unsuspecting user to a fake
web site looking and acting like trustworthy site of some brand). Because the site looks credible
the user often submits his/her personal data and even credit card number. Invitations to visit the
site are usually contained in e-mail messages with a fake return address. CGI scripts usage is
the next Web server threat, as far as many of CGI scripts contain program errors, which can be
used as loopholes by malicious persons. Java and JavaScript usage is one more problem to be
concerned with. Unlike CGI scripts Java code is run on a client side and that is why cannot
damage a Web server, but can contribute troubles to a client. Ensuring secure usage of Java and
JavaScript is based on a browser used by a client. Many of these problems appear as a result of
the errors in Java interpreters used by the browsers.
On the other hand another technologies used in a portal (such as sharing documents, support for
virtual, distributed working teams, usage of different communication tools and protocols, data
repositories, publishing systems etc.) need protection against their own specific types of threats
leading to different local and remote attacks. For example besides many basic possibilities
many portal solutions have tools for information publishing that essentially increases risk of
distribution of data containing malicious code: viruses, Trojan programs, malicious mobile
applications etc. There is also a problem of construction of secure authentication and
authorization subsystems while integrating several automated systems into a portal.
In such a short paper it is impossible to mention all the aspects of Intranet portal security (we do
not make it our aim) — as a typical information system any Intranet portal is subjected to all
typical attacks on it. But even such a brief analysis of its components has uncovered safety
problems facing a portal developer (and no doubt its owner) to make it a trusted tool for
business. Thus a portal application, such as that required by the consumer self-service solution,
must include robust security. It means more emphasis on portal resources’ security including
such an important items as privacy, content integrity, recognition, accessibility etc. As far as
the majority of them require safety assurance, it is reasonable to elaborate implied Intranet
portal security requirements and a complex approach to their realisation in the form of an
information protection subsystem as an integral (build-in) part of a secure Intranet portal.
3. PORTAL SECURITY POLICIES AND REQUIREMENTS
According to the classical approach to the information security maintenance an Intranet portal
should support three basic characteristics — confidentiality, integrity and availability.
Technology and computers cannot safeguard information automatically. It is necessary to
protect portal resources' and clients' information related to using this service.
As usual an Intranet portal needs two types of portal-based Web presence: an internal site for its
employees ("Inportal") and a public portal for its customers and partners (Extranet portal or
"Outportal"). There are different security requirements for these portal types defined to protect
portal resources from two classes of attackers - insiders (corporate employees) and outsiders
(partners, remote users and so on). Inportal should provide more information and services to its
users while Outportal should have essentially stronger restricting and user verification security
policies. Presence of written, approved, maintained and communicated security policies for all
Intranet portal components and users is critical. Without Intranet Portal Security Policies
(IPSP) there is no general corporate security framework. They provide guidelines to users on
processing, storage and transmission of portal resources and define what behaviour is and is not
allowed. IPSP consist of policies for acceptable use, user account and password, remote access,
intranet and extranet, information protection and many others [3, 4]. They must be concise and
easy to understand, implementable, updated regularly to reflect corporation evolution,
monitored and enforced and balance protection with productivity. IPSP also should state
reasons why policies are needed; describe what is covered by them (whom, what and where);
distinct levels of information sensitivity/access; be concerned about internal users as much as
external users; define contacts and responsibilities to outside agencies; discuss how violations
will be handled. IPSP awareness should be a part of employee orientation and education
sessions concerning an Intranet, its portal and their security, should be conducted regularly.
While many definitions of security mechanisms exist, for the sake of simplicity the list of key
Intranet portal security requirements should be defined as follows: identification and
authentication, encryption, centralized and local audits and access control [5].
Authentication is the verification of one's identity. It confirms that users are who they say they
are. For example, a user must provide a user name and password and/or biometric feature that
are checked by an authority (for example a database or a domain server). Authorization is the
process of granting/denying access to resources for specific users. It represents the permissions
that a user/group of users has on a particular resource(s). Both authentication and authorization
of portal resources (such as portlets and pages) should be controlled by a centralized security
mechanism managed in one central repository. Intelligent password policies should be
implemented, encompassing common user and password formats, retry limits and password
update rules.
There are a number of communication flows in Inportal and Outportal. Using encryption
protocols and Virtual Private Networks inside and outside an Intranet ensures that these
transmissions are confidential and transmitted information keeps integrity.
A secure portal is designed to be an application that is integrated to a centralized security access
manager and constantly been audited. Having too many resource objects can be complicated to
manage and can yield an overhead in the authorization lookup. A general rule would be to place
shared or enterprise resources under Intranet central management and leave fine-grained control
in the portal. The portal code in this model is granted unrestricted access to all resources it must
access on behalf of the users. The access control is effectively shifted from native resource
access control subsystems to the portal access control subsystem. Elevated privileges of the
portal code make it an attractive target of malicious attacks, because compromising only one
server gives access to all resources that were accessible to legitimate portal users. Also, the user
registry structure design needs to take into consideration any planned integration at an
enterprise-wide level.
Thus well-designed portal technologies combine standard processes for inventorying and
organizing sources of information, identifying users of that information and establishing rules
for granting and controlling access. Furthermore, an enterprise-level portal access management
solution should provide flexible administration models for cost-effective and time-efficient
management; easy integration with Web-enabled enterprise applications and legacy information
sources; open interfaces and support for standard technologies enabling rapid deployment of
new services; real-time monitoring; scalability to accommodate a continuously growing global
audience; strong universal security. Therefore while designing an Intranet portal it is necessary
to define its security requirements first of all. The suggested here list marks only the most
important requirements divided into six main groups. It does not pretend on the completeness,
because it can be easily extended depending on the specifics of the future Intranet portal usage.

3.1. General Security Requirements

• All portal user actions must be logged. The level of log detail has to be explicitly defined.
• Third party or in-house developed protection software and hardware products (like firewalls
and intrusion prevention and detection systems) must be chosen for the server protection.
• While interacting with the portal Web interface the user must not see any interface controls
(links, buttons, etc.) performing actions that are not authorized by user’s privileges. In
particular the user should be able to view only specific help topics describing actions that
can be done with the privilege set of the user and the search function must return links only
to resources the user has access to.
• The portal developer must define allowed for normal operation and administration network
traffic types. Other traffic types must be blocked by the portal protection systems…

3.2. Access Control Model Requirements

• The user registry stores user accounts holding information about access control to different
portal functions.
• The users must be able to submit registration requests. Only authorized users
(administrators) can create/delete user account after the verification of the submitted data.
• The portal must include the functionality to logically consolidate users into groups/roles in
order to assign privileges to groups.
• The authorization to use any function of the portal must be granted by assigning the
corresponding privilege to user accounts or groups, to which the user account belongs. The
user, belonging to the group, acquires all privileges assigned to the group.
• The list of privileges with the descriptions of all possible actions, which can be carried out
via the Web interface with the assigned privilege, must be defined.
• Access to all portal resources requires the process of authentication and authorization with
every Web request.
• Registered users can submit their information units in different formats via file upload or e-
mail. Only the administrators can introduce the submitted material into the portal databases
after verification.
• Only the administrators should have access to database management functions.
• After defined by the administrators period of inactivity the user session must be closed…

3.3. User Data Verification Requirements

• All data, submitted by the user to the portal via Web interface, must pass the correctness
check (the lack of control symbols, valid code page, etc.) to minimize the security risks…

3.4. Portal Software Requirements

• All portal software must be installed and configured with the least privileges principle.
• All software packages that are not necessary for the portal operation must be removed from
the portal servers.
• An analysis of configuration parameters and their default values for used software
(including OS, Web server…) must be conducted to determine their influence on security…

3.5. Error Message Requirements

• Every error page of the Web interface must display directions on error troubleshooting and
also include contact information of the portal administrators. The page with the error
message must not include any data about any internal mechanism or process and current
state of the portal led to the error (the requirement is aimed at minimizing the amount of
detail available to the malicious person willing to compromise the portal)…

3.6. Development Process Requirements

• All development data transmitted via the Internet (program code, configuration files, user
account data, etc.) must be encrypted.
• Before installation of new software versions during the development or testing all existing
previous versions must be uninstalled.
• The development (source code editing, configuration parameters experimenting, testing,
etc.) on the portal servers is prohibited.
• In case production and development server are the same all software must be reinstalled on
a wiped, data-free hard disk before launch to production…

4. SECURE INTRANET PORTAL MODEL

And how to design a secure Intranet portal to meet the listed security requirements? Some Web
application servers and portal servers provide native built-in security functions for
authentication, authorization and auditing. These might be sufficient for many portal
applications. However, an External Security Manager will provide higher functionality than
native solutions. In addition, an External Security Manager allows centralising security
management across the applications in e-business. There are two possible design alternatives.
1. Built-on information protection subsystem (IPSS). This approach is invariant if it is required
to protect the already operating portal. However it has some essential disadvantages. IPSS for
an existing Intranet portal is harder to develop since we are imposed to adjust in all to portal
designer’s decisions, who did not take into account the possibility of IPSS presence. To detect
vulnerabilities and to eliminate holes in protection are harder than to design a complex strategy
to a whole portal security. The protection continuity principle implying taking the
corresponding measures on a portal protection at all stages of its life cycle is broken. IPSS
requires additional system resources for its operation. Build-on IPSS is more expensive than
similar built-in IPSS developed simultaneously with a portal. Thus built-on IPSS is non-
optimal for security insurance and from viewpoint of system resources sharing. It is labour-
intensive, bulky and requires additional expenses.
2. Complex portal and IPSS development with External Security Manager. It is reasonable to
implement simultaneous and comprehensive development of a portal with a built-in (integrated)
IPSS. Such an approach allows to take into account all necessary security requirements from
the very first designing stage and to ensure an efficient and holistic secure Intranet portal.
While designing a security system, a business needs to consider not only the functions needed to
protect the portal application, but also consider the management of the security system. The key
component is a single, central Security Manager that activates required Security Services in
addition to the other systems in a portal solution. The basic subsystems in the overall reference
secure Intranet portal solution meet listed security requirements are suggested in Figure 1.

Security Manager

Portal Policy/ Authentication Directory

Server Authorization Proxy Server Server
Server

Policy Application Trust Association User User

Store Server Interceptor Registry Repository

Figure 1. Secure Intranet Portal Architecture

1. Portal server (PS). The portal engine is responsible for the execution and rendering of the
portal. It uses one of the APIs to determine the access rights on a resource.
2. User registry (UR). This is a database containing user account information, typically a user
ID and password. It is used in the modern Single Sign-On systems.
3. User repository. This is a database, which contains user profile information, for example a
name or an address. It is possible for the UR and User Repository to be the separate data stores.
4. Directory server (DS). This subsystem provides the authentication information from the UR
and the user profile information from the User Repository. Information maybe accessed and
updated through the Lightweight Directory Access Protocol (LDAP), an open industry standard
for DS. For the UR there is a choice between using DS or Custom Registry. When using an
External Security Manager, it is more or less implied that a DS will be used. However, in a
stand-alone secure Intranet portal, either can be chosen. Choosing LDAP would allow for easier
integration to an External Security Manager at a later stage.
5. Application server (AS). It is responsible for all basic portal services (including for example
document access, groupware, indexing engines, application gateways, knowledge applications,
etc.), one part of which is Security Services.
6. Authentication proxy server (AP). All requests and responses are directed through the AP. It
is responsible for managing the authentication process. It uses the DS to access the UR for user
ID and password information. A reverse proxy is a component that is generally used to perform
URL mapping and manage user sessions (for example with SSL authentication of both the client
and server) in order to protect the Web site's structure from the outside world, but it can also be
used for authentication. This would typically locate in a Demilitarized Zone (DMZ) in front of
the portal. This extra protection would then influence where to use SSL. Another example is to
have the External Security Manager in its own DMZ.
7. Policy/authorization server (PAS). It is responsible for the system security management.
PAS maintains the master policy store with authorization and access control data. It offloads
the tasks of authorization decisions to the PAS when requests are made.
8. Policy store (PS). The PS as a repository of groups and access control lists (ACLs) is used by
the PAS for resources’ access control.
9. Trust association interceptor (TAI). It is responsible for establishing trust between the AS
and the PAS. It validates the request and provides the user ID to the AS obtained from the PAS.
10. Security Manager. It coordinates all security tools managing a distributed, constantly
changing environment.
Processes of portal users' authentication and authorization (after authentication) are listed in the
Table 1.

Table 1. Authentication and authorization processes

Authorization: accessing a secure
Authentication of a portal user
portal resource
1. The request is received by the AP. The prerequisite is that the necessary
2. The AP determines that this is a secure resource and user credentials exist for the client.
therefore challenges the user for authentication (e.g., 1. The request is received by AP.
HTTP authentication or form-based logon). 2. The AP forwards the user
3. The client responds with user ID and password. credentials to the AS.
4. The AP authenticates the user ID and password 3. The user is already authenticated
against the UR. Once authenticated, a cookie for the so the request is forwarded by the AS
client to use for future identification is created. to the PS.
5. The AP then places the user credential information 4. The PS then checks the authority
into the HTTP header and forwards the request to the rights for the requested resource.
AS. 5. The PS queries the PAS for the
6. The AS captures the request and calls the TAI to users/user groups’ membership for a
obtain the user's credentials. particular portal role for that
7. The AS then performs a lookup of the user in the resource.
UR. If this is successful, the AS creates a token to 6. The permission level is then
identify the client. deduced and a successful/
8. The request is then passed to the PS and the output unsuccessful output is returned as
returned through AP to the user. appropriate.

5. IMPLEMENTING SECURE INTRANET PORTAL

There are two possible ways of practical implementation of Intranet portal security. First one is
to buy one of the well-known portal solutions (such as IBM WebSphere, Microsoft SharePoint
Portal, etc), relying on experts' estimations of their security. At present the portal software
industry is aware of corporations' security needs and is responding correspondingly [6]. The
second solution is to create corporation's own portal software with all necessary Security
Services considering its specific operation and environment or to give to a portal developer a
technical project on working out a specialized secure Intranet portal, focused on the enterprise-
customer functional and security requirements.
The basic portal protection methods, being necessary for use in the suggested reference model,
are strong subject authentication, fine-granted access control to portal resources, planning
correct solution architecture, security events audit (including control, account and analysis
resources using and submitted user data verification) and also internal resources’ protection.
Implementing portal security requires usage of some standard security concepts, for example,
encryption (SSL/TLS). Support for industry standards (such as LDAP, NTLM, NIS and NDS)
allows organizations to easily carry over existing security profiles and meet even the strictest
security requirements to the Intranet portals. Monitoring tools used for analysis of all
interactions with a Web server should be also stipulated.
When creating an Intranet portal it is necessary to use the most tested development tools,
avoiding usage of unverified or untested libraries of scripts, patterns etc. A designer should find
a compromise between the newest and the most tested versions of development media.
The "InfoWar" (from "Information War and Information Weapon") portal developed at the
Information Security Faculty of the MEPhI under the support of the Russian Foundation for
Basic Research (project N 04-07-90382) is an example of a secure Intranet portal created
according to the briefly described complex approach taking into account the suggested key
security requirements. The portal in the Russian language is initiatively developed to address
some information security issues and to help in teaching the topic at the higher school in Russia.

5.1. "InfoWar" Portal General Architecture

The portal is built on the Microsoft technologies (the MEPhI has strong relationships with
Microsoft through its Microsoft Academic Alliance Program). Microsoft Desktop Engine, a
free version of Microsoft SQL Server, lies in the portal core. The Web interface is constructed
with the help of Microsoft ASP.NET, the Web development framework. The components
(written in C# language) that glue together MSDE and ASP.NET run on top of the .NET
Framework. The user should interact with the Web portal via a relatively modern Web browser.
A declarative language, similar syntactically to HTML or XML, characterizes ASP.NET. Pages
described in it are transformed into any installed .NET compliant language source code and then
compiled into a class. The class produced is responsible for rendering HTML mark-up to the
user’s browser. The ASP.NET parser builds the source code for the class in a special way so
that when the class is instantiated it will contain all language elements, which were in the
declarative page, as a tree of individual objects. The objects represent the innate property of the
ASP.NET syntax that all elements of the declarative language can contain (nest) the other
elements. In essence each of these objects in memory is an instance of the corresponding class
that maps to every element of the ASP.NET language. Such classes are referred to as the Web
controls. Every Web control is responsible for rendering its own portion of the HTML mark-up.
Some additional units are required to run the portal. The first one is URL rewriting engine used
to transform the incoming URL http://war.fis.mephi.edu/foo/ into http://war.fis.mephi.edu/
bar.aspx. The second is a specialized class representing the core <form> HTML element. The
third is a template framework. Every portal page contains special content elements that nest
actual content pieces. The template that affects all portal pages contains special placeholders
where these content elements are embedded.
When a request arrives to the portal server, ASP.NET instantiates the class for the page and
begins processing the request by calling the methods of this class in a defined order driving the
instance of the generated page class through its complete lifecycle. The generated page class
requests the template parsing and compilation. Then the template is instantiated similar to a
normal generated page. As the final step the page and template trees are merged with the help
of the content Web controls of the page that are inserted instead of the corresponding content
placeholder Web controls in the template.
All source code is partitioned into several major namespaces (IWPortal.Core, IWPortal.Data,
IWPortal.Business and IWPortal.WebUI) and auxiliary namespaces such as
IWPortal.Configuration and IWPortal.Mailing.
The portal is designed with the classical 3-tier (Presentational, Business and Data) architecture
in mind. The bottom Data tier is responsible for moving the data between the instances of the
objects in memory and tables in the relational database. Every data table in the database has a
corresponding data object, which resides in the IWPortal.Data namespace. These objects,
referred to as data objects, act like proxies between objects in the Business tier and tables in the
database. The Business tier is responsible for enforcing the logical rules of portal-user
interaction. They include security enforcement according to the access control model described
above. Many classes in this tier inherit directly from their Data tier counterparts. For example,
a User object is inheriting directly from UserDataObject. The user object contains no
functionality for database access. It passes control to methods in UserDataObject when it is
need to persist an instance of the User class or retrieve it from the database. The highest
Presentational tier is essentially a set of ASP.NET declarative pages and corresponding classes.
Most of the classes belong to the IWPortal.WebUI namespace. The separation into tiers yields
clearer and maintainable code, which gives two main specific advantages. Firstly, the database
can be easily swapped. If the portal outgrows MSDE capabilities it can be migrated to MySQL
or other free database. This will require minimal changes in the Data tier only. Secondly, the
code maintenance becomes easier as bugs can be identified and fixed faster due to code
separation and isolation into the individual partitions.

5.2. Implementation of the Security Subsystem

The “InfoWar” portal security is provided by its functioning logic. It realizes protection against
the most trivial and most probable attacks. It is supposed that an intruder is an authorized portal
user and he/she has at his/her disposal only a browser via which he/she gains access to portal
resources and components. Though browser opportunities are limited, however it is enough for
example to read the Web page contents (in a form of HTML code) and the entire client side
scripts. Because of the native browser features the user can type any address and gain access to
a page, which is not referenced anywhere. He/she can transfer any parameters including forge
ones. The Portal IPSS detects all these activities, reacts in an appropriate way and logs any
attempts to compromise the portal. Protection against information substitution and deleting is
also implemented via strict access control.
The process of portal user registration consists of the several steps. The user fills in the
registration form and types his/her e-mail address. The system sends to user's mailbox a
message with the confirmation code. After reading the message goes to the special URL and
enters the confirmation code. After the automatic verification of e-mail address a portal
administrator checks other fields of the registration form for correctness. The administrator may
contact the user via e-mail to gather some additional details that were not typed or were typed
incorrectly. If the personal data is correct, the administrator registers the user. The system
sends to the user the auto-generated password for the portal access. It is important that portal
users are not allowed to choose their own passwords. They get a random character string. This
makes brute force and dictionary attacks very hard to succeed. The login form is present on
every portal page in upper-right corner for user convenience.
Security subsystem logic consists of a special business class called SecurityMonitor that is
essentially an IPSS and several business classes, which inherit from data classes in
IWPortal.Data namespace. SecurityMonitor incorporates all functionality supplied by the
 different servers in Figure 1. The separation into discrete components is not required because
the user base is relatively small (while comparing with a huge corporation).
All security rules are enforced by the SecurityMonitor class. The generated page class for every
declarative page inherits from the specially created SecuredPage class. This class is marked as
abstract because of the special abstract PageType property implemented by the inheriting code
behind the class. The PageType property returns a value of its enumeration that holds all
possible page types. The SecuredPage class contains also an implementation of the
SecurityCheck() method which acquires the value of the PageType property and supplies this
information along with the username to the SecurityMonitor class. This class creates several
instances of the business classes such as User, Group and Privilege and performs database
lookup in order to determine the resulting privilege set and to allow the user to view the page if
the privilege set is sufficient. Otherwise the normal page processing is interrupted and the
browser is redirected to the error page with the explanations of the possible error.
SecurityMonitor also enforces security for actions that can be carried out from the page by
clicking the buttons. Because all security checks are delegated to SecurityMonitor, this class
becomes the ideal place to log audit messages about all actions performed by the users. The
current implementation allows to put the audit trail to the plain text file or to the application
event log of Windows Server 2000/2003.
The authentication scheme is based on the modified cookies. After successful authentication the
ASP.NET forms the authentication module that sets the session cookie to track the user. It is
never saved to disk and is destroyed if the browser is closed. Also, the server will reject the
cookie that was not used in requests during the specified time period (on each request the cookie
is updated to reflect the last request time). The users can forcibly logout with the help of the
logout link under his/her username in the Web interface to destroy the authentication cookie.
All administration pages are accessible only through the HTTPS connections. IIS is configured
to use certificate to authenticate itself to the users. Because the clear-text password can be
sniffed the administrators are required to authenticate themselves to the portal with their
personal certificates. Payload protection protocols used are SSL3 and TLS1.0.
The current "InfoWar" portal version will be improved. Protection against attacks on portal
communication channels and counteraction to "denial of service" attacks are to be implemented.

6. CONCLUSIONS
Brief motivation of information security implementation expediency for Intranet portals is
emphasized. Key security requirements for Intranet portal security are suggested. Functional
components of a secure Intranet portal model are listed. A real example referred to as
"InfoWar" developed in the MEPhI under the support of the Russian Foundation for Basic
Research demonstrates viability of the suggested reference secure Intranet portal model.

7. REFERENCES
[1] Horgan T. Developing Your Intranet Strategy and Plan - http://www.cio.com
[2] Christopher C. Shilakes and Julie Tylman, "Enterprise Information Portals," Merrill Lynch, Inc.,
New York, NY, November 16, 1998
[3] http://www.sans.org/resources/policies/
[4] http://www.eff.org/Censorship/Academic_edu/CAF/policies/
[5] IBM redbook - http://www.redbooks.ibm.com/
[6] David K. Black. Portal Security: Managing Identities and Relationships in a Competitive
Economy - http://www.accenture.com/xdoc/en/ services/secsol/insights/portal.pdf

View publication stats