Single Sign-On Feasibility

infestationwatchSoftware and s/w Development

Oct 28, 2013 (3 years and 9 months ago)

54 views

Single Sign
-
On Feasibility

January 2002




S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE


Table Of Contents


1.
INTRODUCTION
................................
................................
................................
.........

3


2.
ORACLE 11
i

................................
................................
................................
.................

4

2.1 Technical Overview

................................
................................
................................
................................
............

4

2.2 Approach

................................
................................
................................
................................
...............................

5


3.
DATA STREAM 7
i

................................
................................
................................
.......

5

3.1 Technical Overview:

................................
................................
................................
................................
...........

6

3.2 Approach

................................
................................
................................
................................
...............................

6


4.
GELCO
:

................................
................................
................................
.........................

6

4.1 Technical Overview:

................................
................................
................................
................................
...........

6

4.2 Approach:

................................
................................
................................
................................
..............................

6


5.
PEOPLESOFT
:

................................
................................
................................
.............

7

5.1 Technical Overview

................................
................................
................................
................................
............

7

5.2 Approach

................................
................................
................................
................................
...............................

7


6.
CONCLUSIONS
:

................................
................................
................................
..........

7





S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE


1. Introduction


The NIH New Business System project is replacing NIH’s own custom administrative
applications with third
-
party off
-
the
-
shelf applications. There are 5 prinicipal
applications involved i
n the implementation. They are:


1.

Oracle 11i (accounting system plus other modules)

2.

Gelco Travel Manager 8 (T&E application)

3.

Compusearch PRISM (large contract procurement application)

4.

DataStream MP5i (asset warranty and maintenance application)

5.

Peoplesof
t 8 (HR and payroll application)


These applications are replacing a custom system (ADB) which had ‘single
-
signon’
because the whole system was developed from scratch by NIH itself. So without SSO,
the feeling in the NIH community is they are taking a ste
p backward. Furthermore,
multiple sets of credentials for many different applications heightens concerns over
security as multiple userid/passwords are shared with others, written on sticky pads, or
are kept so simple as to be easily compromised. Also i
ndustry studies have shown that the
chore of remembering multiple credentials increases administrator and help desk calls
significantly cause of forgotten passwords and frozen accounts. Also the absence of a
central authentication system and the lack of a
coordinated process between the disparate
systems dramatically increases the risk of orphan accounts in various systems from ex
-
employees and associated security risks of their misuse. With security management
software, NIH adds the capability to provide s
ingle user credentials for all their desktop
and web systems, the feature of signing in only once for access to all its web systems,
increased security by adding stronger authentication mechanisms and by tying its
credentials to existing secure credentials

databases like the NT Domain and/or Active
Directory environments already in use. More than the centralized maintenance it is
possible to distribute maintenance across multiple departments. NIH also benefits by
gaining the capacity to define security poli
cies at a more granular level to all its web
resources and independent of any single application.


NIH engaged KPMG Consulting in identifying a security management product and
developing a proof of concept/prototype SSO with one of the above 5 applications
. Of the
two leading vendors in contention (Oblix and Netegrity), KPMG with inputs from NIH
and their central information technology department (CIT) identified Netegrity as the
security management vendor for the prototype. The proof of concept for the sin
gle sign
-
on was demonstrated with Compusearch PRISM and Plumtree portal using Netegrity’s
Siteminder software. KPMG developed integration and modifications to the Prism
software to enable single sign
-
on. Working with Compusearch’s development team
KPMG pro
vided them with these designs and modifications to be included in their base
line product.




S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE



This approach of designing, developing changes and working with the vendor to have
them incorporated in the baseline software proved to be a win
-
win for both the c
lient and
vendor (Compusearch in this case). Compusearch shared its product code base to develop
the changes while KPMG helped them add a much desired functionality to their product.


This document describes the feasibility, approach and timelines of enabl
ing single sign
-
on with the remaining four applications in the NIH new business systems project. What
follows are the technical challenges of each application and the proposed approach to
enable single sign
-
on with each.


2. Oracle 11i


2.1 Technical Overv
iew


Oracle 11i application is a fusion of at least 3 different architectures.
Technologically Oracle 11i is best described as a work in progress, a potpourri of
modified client server technologies and web technologies. The basic platform used to run
this

assembly is the Oracle application server(iAS) running on Apache. The architectures
and technologies used by the application are Java Server pages (JSP), Servlets, PL/SQL
Cartridges, Oracle reports server, forms server and Oracle Discoverer. Most of the
above
technologies do not inherently interoperate with each other. Oracle achieves this by a
series of handshakes orchestrated through the backend database server. This makes the
task of enabling SSO in Oracle especially challenging. Oracle does not suppo
rt single
sign
-
on with any non
-
Oracle product as of this writing. Even within its own products
Oracle is currently in the process of adding this functionality. Oracle has indicated that its
future product direction is to support SSO solutions like Netegrit
y and Oblix. But no
release dates have been set. Explained below are the three different architecture threads
that run in the application and our approach to enabling SSO.


Architecture 1
:

Oracle self service applications have a HTML/Javascript front end a
nd
use the Servlet engine and PL/SQL cartridges to dynamically generate the front end. The
PL/SQL engine first receiving the request from the web listener and the PL/SQL
cartridge orchestrating the different calls to servlets and jsp pages to generate the
final
content. However Oracle’s future direction in this regard is to phase out the PL/SQL
engine and have all the middle layer encapsulated in the JSP/Servlet engine. And phase 3
after that is to integrate J2EE technologies into the mix in the middle laye
r. However
J2EE technologes and the JSP/Servlet architecture are complimentary to each other and
in fact JSP/Servlets are one of the key pieces in the J2EE architecture. As explained later
it is this particular architecture of the three that provides us wi
th an access approach to
build an extension to enable single sign
-
on.




S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE



Architecture 2
: The second architecture in the application used by the business
intelligence system runs on a combination of the reports server, discoverer and Database
server. The Disc
overer manages workbooks and views and the data is presented to the
viewer via a client applet or HTML viewer. This architecture is an extension of Oracle’s
prior Reports client/server architecture to a web based one.


Architecture 3
: The third architectur
e used by the ‘professional interface’ or in other
words the user interface comprises of the reports server, forms server and database. The
database of course being the common layer in all the architectures. The user interface
forms are displayed to the us
er via applets running on the Oracle Jinitiator JVM plugin in
the browser. Java code needed for the applets is downloaded as needed and cached on the
client machine. Any field navigation on the applet form generates a server call on the
forms server. The a
pplet and forms server communicate using compact runtime messages
via http or https.


2.2 Approach

There are two approaches to developing single sign
-
on integration with Oracle
11i. The first approach is to identify the changes required in the software and

work with
Oracle to develop the modifications to the software. Also as mentioned above Oracle has
already indicated that the future direction of its product is to support single sign
-
on
solutions like Netegrity Siteminder and Oblix Netpoint. So a slightly

modified first
approach would be to ascertain exact release plans for the feature from Oracle and
developing infrastructure and modification required outside to co
-
ordinate with the
release.


The second approach is to develop integration code outside of
the software which
will interface seamlessly with the application to provide single sign
-
on functionality in
the application. As indicated above the first architecture in 11i provides us with an access
approach to develop this integration module. This will

not involve any business layer
changes to the 11i application other than minor cosmetic changes to the JSP layer UI
templates. Since this does not change any of the existing business codebase this provides
an easily manageable non
-
intrusive method to deve
lop and manage the modification. This
proposed integration module will be a servlet interfacing with the existing servlets in the
11i application and invoking PL/SQL cartridges using Oracle’s communication protocol.
This module will also be compatible with

future releases of 11i requiring, if at all, very
minor parameter changes in the configuration file.


3.0 Data Stream 7i





S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE


3.1 Technical Overview:

Datastream 7i is built on Oracle technology namely Developer forms, Internet
application software (iAS) platf
orm and database stored procedures. As such its
architecture is similar to the third architecture mentioned in the Oracle 11i overview
using the forms server and database. However the similarity ends there. However unlike
Oracle the Datastream uses this ar
chitecture consistently throughout the application. So
the front end user interface is comprised entirely of applets, the forms middle level layer
and the database bringing up the rear. Datastream currently does not support single sign
-
on capability and ba
sed on our research there are currently no indications that it is slated
to be included in future releases.


3.2 Approach

Due to its applet and forms architecture it is not practical to develop independent
software extensions to the software for enabling
single sign
-
on. Enabling single sign
-
on
would involve modifying the applet security classes in the software. Similar to the
manner it was done with Compusearch for the prototype this would involve the
participation of the Datastream to share their codebase

or incorporate the proposed
changes. KPMG will help design and indicate/make the specific modifications required to
the software. Failure or resistance by Datastream to co
-
operate in this effort might pose a
risk SSO enabling Datastream 7i.


4. Gelco:


4.
1 Technical Overview:


Gelco travel manager is built on Progress software's webspeed workshop
and WebSpeed Transaction server. This is Progress proprietary technology with support
for HTML and applet based front ends for web based applications. The Product

has a
three tier architecture and uses either a cgi script or NSAPI/ISAPI plugins on the
webserver. These plugins interact with the WebSpeed application server to conduct
transactions and return dynamic html to the client. The webserver/plugin and applica
tion
server form the middle layer, the browser forming the front end and database bringing up
the rear. Gelco currently does not support single sign
-
on. However based on our
discussions with Gelco personnel single sign
-
on customizations have been provided
in
the past for other clients.


4.2 Approach:

Single sign
-
on capability can be developed for Gelco in two ways. The preferred
approach being to provide Gelco with the design and modifications required and working
jointly to incorporate the changes into the

product. Given their current architecure this
can be done without significantly changing their product design.





S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE


Their product architecture also provides us with a second vendor independent
approach. This would involve development of external module extens
ions to the software
which will interface seamlessly with the product to provide SSO capability. Similar to
Oracle's second approach these servlet extensions would require no modifications to the
software and would be fully compatible with future versions.



5.0 Peoplesoft:


5.1 Technical Overview


Peoplesoft with the release of its version 8 systems completely revamped its
product to an internet architecture. Its user interface is dynamic html and its business
layer comprised of servlets, the Tuxedo Jolt t
ransaction monitor and application server
components. Peoplesoft 8 also allows the management of all end user security profiles in
a centralized repository like LDAP. In fact,
PeopleSoft directory server integration goes
beyond authentication to drive the
creation and maintenance of LDAP user profiles based
on business events in the PeopleSoft applications. For example, when employees are
hired or change jobs, their security profiles can be updated automatically. Given that
Peoplesoft HRMS is the master emp
loyee repository at NIH, the above feature coupled
with the single sign
-
on approach to all enterprise applications could provide a seamless
and ‘automatic’ way to provision and disable accounts for employees and ex
-
employess
respectively enterprisewide. Pe
opleSoft Internet Architecture also supports single signon
to other PeopleSoft and non
-
PeopleSoft applications and it integrates with other third
party authentication and public or private key technologies.


5.2 Approach


With its SSO ready capability, im
plementing SSO for Peoplesoft will probably be
the most straightforward of the four. Requiring installations and configurations of single
sign
-
on extensions from Peoplesoft and integrating them with the SSO infrastructure at
NIH.



6. Conclusions:


As more

of the existing corporate and business infrastructure moves to the web
supporting single sign on for all product vendors is fast becoming a necessity. Single
sign
-
on not only delivers an integrated set of "shared" security and management services,
it enab
les companies to centralize authentication and access control, and leverage these
services across all users and applications on an e
-
business/corporate web infrastructure.


As assessed above Single Sign
-
On can be implemented with all the
aforementioned NI
H applications. With the exception of Datastream 7i, SSO



S I N G L E S I G N O N F E A S I
B I L I T Y




NATIONAL INSTITUTES
OF HEALTH

NEW BUSINESS SYSTEMS

JANUARY 2002

FEDERAL PRACTICE


implementation for all the applications can be achieved with or without vendor support.
That being said however the preferred approach is to work with the vendors to implement
the functionality and t
o take the second approach if the first provides too many obstacles.
In the case of Datastream 7i though perfectly doable, because of its product architecture
and configuration implementing SSO would require collaboration with the Datastream
product team.