Novell is now a part of Micro Focus

How to Use the Security Features in Novell Portal Services

Articles and Tips: article

J. Jeffrey Hanson
Chief Architect
Zareus Inc.
jhanson583@aol.com

01 Feb 2002


Novell Portal Services are integrated with directory services technology and capitalize on the inherent security features of directory services. This article discusses the security features in Novell Portal Services taking a deeper look at gadgets, portal configuration objects (PCO), Secret Store, and Single Sign-On.


Topics

Novell Portal Services, security, Web applications, single sign-on

Products

Novell Portal Services

Audience

administrators, developers

Level

intermediate

Prerequisite Skills

familiarity with directory services technology

Operating System

Windows 95/98/NT/2000, NetWare

Tools

none

Sample Code

no

Introduction

Easy access to internal information through a Web browser is provided by portal Web sites; for companies providing access to vital data, reports, applications, and processes. Providing access to resources such as file system services, collaboration services, print services, etc. is the Novell Portal Services (NPS) framework for developing portal Web sites. Components known as Gadgets are used by NPS to separate the portal pages into diverse pieces of business logic and content.

Time and complexity of deploying secure, personalized portal-pages to every member of an organization is reduced by NPS. User access, content presentation, and portal administration based on each user's business context is automatically managed by NPS, thus creating a personalized, secure environment.

Security for highly personalized content to any Web-enabled device of a company's employees, customers, and partners, based on attribute, role, group membership or organization is possible via NPS.

Novell Portal Services Security Features

The NPS core component, NPS servlet, is platform independent and written to open, widely-used industry standards. NPS is built entirely on industry standards (e.g. XML, XSL, LDAP v3, Java, and HTTP).

By securing information with directory access controls, only those to whom an administrator grants access can see it. This is how NPS controls access to information. Existing Web applications, that already have a Web interface, can also be easily migrated to NPS. NPS can provide single sign-on for these Web applications. User-access to applications can be simplified by making them available through an NPS portal.

Hesitant to make their network resources available to the public, businesses have for one primary reason been cautious: security. A portal's effectiveness is directly related to how manageable it is once it is up and running. Two benefits of directory-enabled solutions are security and manageability.

Security controls inherent to directories-access control and authentication, are exploited by NPS to prevent one's portal from becoming an entryway to uninvited guests. The degree to which one's network is exposed to users is strictly limited by NPS. Exactly which parts of a user's network are accessible are determined by building gadgets to expose those parts. A user would not provide a gadget that accesses a particular database through a portal if he/she did not want anybody to access it. NPS also restricts what users can do: they can follow links, click on buttons and check boxes, but they cannot send commands or executables through the portal unless they are authorized.

Gadgets

A customizable and executable entity within a portal is known as a "gadget" in NPS jargon. A gadget "owns" part or all of a portal page. Gadgets provide access to resources such as directories, databases, and Web pages. A gadget provides the necessary data and layout to render its piece of the page.

A gadget will return both an XML data stream and the URL of an XSLT stylesheet to transform the data into HTML for display. Gadgets typically perform actions based on input from a user. Most gadgets also interface with one or more external data source.

By interacting with several network components to retrieve data, gadgets can also perform complex tasks. For example, a gadget accesses data sources such as databases on the back end by calling the Java Database Connectivity (JDBC) API. The NPS API enables a gadget to read settings and access information from a directory. Authentication tasks can also be performed by gadgets.

Authentication credentials from a directory, allowing a user to log on to an application, can be retrieved by a gadget. For example, a gadget that is programmed to perform sign-on services, accesses a client's logon information from a directory service. With this information the gadget can logon to a back-end database, retrieve the information and present it to the NPS servlet as an XML stream.

Configuration Settings

The NPS installation program extends the directory schema to include new objects when you install NPS. These extensions include the portal configuration object (PCO), gadget objects and a public portal user. The PCO is the central portal management object and manages all information for the portal. Even when multiple servers host the portal, only one PCO exists for each portal.

A Web server uses the following two property files for configuration:

  • The GadgetRunner.properties file, which specifies the gadget to run and the username and password for the user.

  • The ConfigData.xml file, which contains configuration settings for a gadget.

The GadgetRunner.properties file contains four parameters: GADGETCODE, USERDN, USERPASSWORD, and RENDER, defined as follows:

  • GADGETCODE: Indicates the gadget code to be used. This parameter must be set to the gadget's fully-qualified class name. The class must be in the system classpath.

  • USERDN: When getting the username from the Authentication Manager, the DN is specified for the user. The LDAP format (i.e. USERDN=cn=Test,o=testgadget) must modify this parameter.

  • USERPASSWORD: This specifies the password for the user when getting the username from the NPS Authentication Manager.

  • RENDER: This property specifies whether the parser should pass XML or HTML back to the browser.

Gadget configuration settings are stored in an LDAP directory, such as Novell Directory Services in a production environment. However, configuration settings can be stored in a file, ConfigData.xml, which is automatically generated by NPS, allowing the gadget to run independently of a directory.

Portal and Gadget Initialization

Accessed by NPS during its initialization phase, the PCO identifies all installed gadgets and their implementation classes. The GadgetInstance interface is implemented in this process. NPS will then call each onPortalInit method of the gadget's classes allowing any one-time system startup initialization to be performed by the class.

NPS creates a new session-specific GadgetInstance object and then assigns it a unique ID when a user first references a scheme (page) for each gadget in the scheme. State information related to the user's session is stored by these objects, thus, allowing NPS access to this information until the session ends.

User ID and Password Authentication

Access to NPS is gained by supplying a user ID and password to the Registration gadget: com.novell.nps.gadgets.registration.RegistrationGadget.

One can take advantage of a directory service's inheritance structure to control access to network resources. For example, an administrator only has to grant rights to an application in the Accounting Organizational Unit object, if the administrator wishes to make a certain database application available to all accounting personnel. To all the other objects subordinate to the Accounting Organizational Unit, the rights to that application flow downward.

Directory services are used to easily manage access rights to all resources on the Web. These rights are controlled by access control lists (ACLs) which are attributes of each object. Whether someone can access or even see network resources is controlled by ACLs. For example, a company's partner information can be configured to be accessible to partners, but inaccessible to the company's internal network.

Logging-on to multiple databases, servers and applications, is made easy by directories. A user's logon information is an attribute of the user's object and is stored by the directory, thus, the directory will retrieve the logon information and log the user on automatically when the user attempts to access a restricted gadget or portal.

One can use a directory structure to fine-tune the customization of a portal if the directory structure mirrors his/her organizational structure. For example, everyone in the company can access e-mail, yet, only the engineering division gets access to a particular engineering database.

If an object scheme is stored in a container object, then all the subordinate objects will inherit that object scheme. Object schemes can be stored in user and group objects. If you want to make a particular application available only to members of the accounting department, you can create an object scheme in the Accounting Organizational Unit that has a gadget for accessing the application. Access to the object scheme with that gadget will be limited to only those users in accounting. A user will automatically gain or lose access to the application when he/she is transferred in or out of the accounting department. The only action needed to make this happen is moving the user's object from one organizational unit to another.

Settings are stored in a user's directory object, and are read by the portal when it is opened. Yet, an administrator can prevent users from modifying the settings as desired. For example, an administrator can restrict modifications to the setting of the location of the corporate news gadget. This will override settings in subordinate objects when NPS reads layout information up through the directory.

Portal groups can be created by specifying that the members of a group consist of users who have a specific attribute consisting of a specific value. For example, if User objects have a Status attribute, a portal group could be created for everyone whose Status attribute was "Preferred". Similarly those with "Gold" in the Status attribute might be a second group and by those who had "Platinum", a third group. One or more object schemes for each of these groups could then be created. The object schemes for a user would change automatically as soon as a user's status changed.

Secret Store and Single Sign-On

Logging on to the Web with single sign-on technology is simplified by NPS. A user only logs on to a portal once instead of providing separate credentials for each of the various applications, servers, Web sites, and databases that the user needs to access. NPS accomplishes single sign-on using two types of authentication:

  1. Every packet that travels across the wire must be accompanied by basic authentication. Some applications require this type of authentication.

  2. By establishing a secure channel using authentication data at the beginning of a session. For example, when a user first accesses a site, NPS will prompt him/her for a user ID and password. NPS then stores this information in the directory and NPS will automatically log the user on the next time he/she visits the Web site.

Each type of authentication uses one of two types of credentials:

  1. Directory credentials are used to log in to a directory.

  2. Unique credentials, used by servers, applications, Web sites and other resources that have not been configured to accept directory credentials.

Out of the box, both types of single sign-on solutions can be performed by NPS. Other types of authentication solutions such as Novell iChain can easily plug in to NPS. NPS stores the credentials in the directory as an attribute of a User object to protect authentication credentials. Each entry is encrypted and stored separately in a "credential store." The entire credential store will become locked if an unauthorized entity attempts to reset a user's password to gain unauthorized access to his/her portal. Even network administrators are prevented from accessing a user's credentials. A user will be notified that the store is locked the next time the user tries to log on to the portal. A user can unlock the store by entering his/her original user ID and password or by resetting the credential store, which erases every credential.

The ability to store encrypted user credentials in the LDAP directory along with a tag that can be used to reference them is provided by the Secret Store. This is important for gadgets attempting to provide single sign-on capability to automatically authenticate a user to a third party service or device.

To make use of Secret Store, a gadget extends BaseSSGadgetInstance. All capabilities of BaseGadgetInstance are inherited while adding support for Secret Store.

A gadget can present the user with a form prompting for credential data by calling displayGetCredentials to generate the appropriate XML. The getUserInformation method can be used to retrieve the credentials from the response, encrypt them, and write them to Secret Store.

Credentials are encrypted by default when using a user's password. An additional encryption key can be supplied and the credentials will be double encrypted if additional security is required. The Secret Store will become locked on the next access if the user changes his/her password. The choice to either unlock the Secret Store by supplying his/her old password or to delete all the locked entries will then be given to the user.

By calling getUserInformation with the same lookup tag that credentials were stored with, a gadget can retrieve and decrypt a user's credentials. Credentials from the Secret Store can also be deleted by calling removeSecret.

Summary

The primary advantage of using Novell Portal Services for a portal solution lies in its solid integration with directory services technology. By capitalizing on the inherent security features of directory services, NPS makes it easy to control who sees what. Since NPS is built to open standards, it is platform independent, interoperable, and easy to adapt to future technologies.

References

How to Get Hands-On Development Help

Novell Developer Labs is available to assist developers who would like hands-on help integrating their products with technologies such as Novell eDirectory, LDAP, DirXML, Novell Portal Services, Novell Modular Authentication Services, and many more. For more information about how you can take advantage of Novell's convenient lab facilities, engineering assistance, and related resources, visit http://developer.novell.com/devlabs.

* 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