The Florida State University: Identity Management & NMI-Component Integration - NMI Integration Testbed
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
NMI Integration Testbed
NMI-EDIT
Identity and Access Management
Case Study Series
The Florida State University:
Identity Management & NMI-Component
Integration
January 2005
NSF Middleware Initiative (NMI) Integration Testbed Case Study Series Series contact: Mary Fran Yafchak, Southeastern Universities Research Association, maryfran@sura.org. The NMI Integration Testbed Program provided practical evaluation of NMI components within the context of real projects and application scenarios from June 2002 through November 2004. During that time, NMI Testbed sites collectively submitted over 220 evaluation reports to middleware component developers as direct feedback into the NMI development cycle. Site representatives also actively inspired, promoted and facilitated the integration of middleware throughout their institutions. The NMI Integration Testbed Case Study Series documents the most significant influences and outcomes of NMI Testbed sites' middleware integration efforts, highlighting intersections with established projects, application contexts and influences, drivers for innovation, decision points and challenges. Through this documentation, the work of these pioneering institutions is captured to provide a breadth of insight and approaches for others to use towards successful middleware development and deployment. This NMI Integration Testbed Case Study Series is sponsored by the National Science Foundation Middleware Initiative-Enterprise and Desktop Integration Technologies (NMI-EDIT) Consortium of EDUCAUSE, Internet2, and SURA. Additional support was provided by the National Science Foundation Cooperative Agreement NSF 02-028, ANI-0123937. Copyright © 2005 The Florida State University. The Florida State University permits use of this content for noncommercial purposes with proper attribution. All rights reserved. FSU: Identity Management & NMI-Component Integration 2 NMI Integration Testbed Case Study Series January 2005
Executive Summary
FSU’s need for a comprehensive, deploying a new solution on their own.
standards-based identity management However, when campus resources were
solution evolved over time, driven by the redirected due to the university’s
increasingly robust and complex IT services reprioritization of IT initiatives, FSU’s IT
FSU offered to its students, faculty and staff. leaders then decided they must retain an
By 1997, Florida State University (FSU) IT outside vendor that could provide a
leaders were searching for a comprehensive comprehensive solution that included
identity management solution to implement consulting, software and maintenance
a secure, single sign-on (SSO) capable, support services. The solution’s design
centralized authentication service on a needed to provide for an enterprise-level
campus-wide basis. metadirectory that would provision data from
the metadirectory to other services and
IT management and technical staff were applications. Through a thorough RFQ
acutely aware not only of the need for SSO, process, FSU selected Novell’s eDirectory
but to discontinue the use of social security product, as only Novell’s solution could
numbers (SSNs) as primary student integrate with FSU’s ERP/People soft
identifiers. Organizational and policy implementation.
changes on campus also created the need
for a centralized directory solution that put As of Fall 2004, the Novell eDirectory
its two Lightweight Directory Access software had been deployed. FSU deployed
Protocol (LDAP) directories on a an adaptation of NMI-EDIT’s standard
consolidation course as part of the new, enterprise directory design to fit with their
single campus directory solution. Novell eDirectory solution and PeopleSoft
deployment. This solution has allowed FSU
The path FSU took in evaluating and to merge their LDAP directories and
determining what their identity management discontinue the inappropriate use of SSNs.
solution should look like was influenced by Also, since Novell’s eDirectory is NMI-
information from Internet 2 and from FSU’s compliant, the solution provides FSU the
participation in the National Science option of implementing other NMI
Foundation (NSF) NMI (NSF Middleware technologies in the future.
Initiative) Integration Testbed. Together,
these groups made clear to FSU the For more information about FSU’s identity
advantages they would gain from management solution, contact Joe Lazor at
implementing an NMI-compliant solution. JLazor@admin.fsu.edu.
Initially, FSU focused their resources on
FSU: Identity Management & NMI-Component Integration 3
NMI Integration Testbed Case Study Series January 2005NMI Components Highlighted in this Case Study The NMI components discussed in this case study series encompass NMI Releases 1 through 4. Information about NMI Releases can be found at http://nsf-middleware.org/. eduPerson Directory Schema eduPerson contains identity-related attributes for higher-education institutions to deploy for enabling inter-institutional collaborations. Home site: http://www.educause.edu/eduperson Conventions and Best Practices These NMI-EDIT documents reflect current NMI research in campus core middleware. The architecture approaches and policies promulgated here are in use at several leading campuses and institutions. Discussion includes “A Recipe for Configuring and Operating LDAP Directories,” “Practices in Directory Groups”, “Metadirectories Best Practices”, and “Enterprise Directory Implementation Roadmap” documents. Home site: http://middleware.internet2.edu/dir/ Shibboleth Software The Shibboleth technology supports inter-institutional sharing of web-based resources subject to access controls. Home site: http://shibboleth.internet2.edu FSU: Identity Management & NMI-Component Integration 4 NMI Integration Testbed Case Study Series January 2005
The Florida State University:
Identity Management & NMI-Component
Integration
The Florida State University, a Carnegie I, This article looks at the research and
public University located in the State capitol evaluation process that served as the
of Tallahassee, Florida enrolls over 67,000 foundation for the decisions that FSU’s IT
students, with 39,000 in residence, 28,000 leaders made as they created their new
on-line with an additional 11,000 faculty and eDirectory solution. Attention will be given
staff. Other resident campuses are located to the understanding the value of basing
in Panama City Beach Florida, London, such a campus solution on NMI compliant
England, Panama and Puerto Rico. software, as well as how FSU’s participation
Organizationally, FSU has 17 colleges and in the National Science Foundation (NSF)
schools responsible for administering NMI (NSF Middleware Initiative) Integration
undergraduate and graduate degree Testbed1 helped them better understand this
programs. Centralized organizations provide value.
financial and administrative support
services, student services and, to a degree,
Need for an Identity
information technology (IT) services.
Management Solution
FSU’s need for a comprehensive,
As they moved into the new millennium, standards-based identity management
FSU IT leaders and staff were developing a solution evolved over time, driven by the
comprehensive identity management increasingly robust and complex IT services
solution that would address several major FSU offered to its students, faculty and staff.
issues inherent in their then current By the late 1990’s, FSU had been providing
infrastructure. Having concluded their centralized academic computing and
solution should be based on NMI compliant network access to e-mail services and an
standards, FSU has since selected and on-line public directory for many years. By
successfully implemented Novell’s 1997, FSU IT leaders were already
eDirectory solution. FSU now provides a searching for a solution to implement a
centralized authentication service that offers secure, single sign-on (SSO) capable,
campus computer users a single sign-on centralized authentication service on a
(SSO) and person identifiers no longer
based on their Social Security Numbers 1
As part of its overall effort to develop and disseminate
software that lets scientists and educators share
(SSNs). resources across the Internet, NMI began a practical
deployment and evaluation effort called the NMI
Integration Testbed. http://www1.sura.org/3000/NMI-
Testbed.html
FSU: Identity Management & NMI-Component Integration 5
NMI Integration Testbed Case Study Series January 2005campus-wide basis. Unfortunately, the (LDAP) directory services - one for
enabling technology was not yet widely accessing the FSU public directory and
available or understood. Yet the need for centralized e-mail services (the academic
such a solution became all the more LDAP directory, or “LDAP1”), the other for
important when, in 1998 and 1999, FSU securely accessing on-line administrative,
broadened its web-based service offerings business support applications and services
by deploying Blackboard for centralized (the business and service LDAP directory, or
content management of its online course “LDAP2”). These two LDAP directories were
development and delivery. on a course that would ultimately lead to
their consolidation into a new, single
FSU’s search for a secure identity campus directory solution. One factor driving
management solution was also driven by the this consolidation was the mandate by a
need to move away from the use of SSNs as Provost e-mail committee that established a
the primary student identifier. In the early standardized naming convention and set
days of the Internet, there was far less policy that e-mail would be an official means
concern about identity theft and individual of communication between faculty and
privacy than in recent years. Thus FSU, like students.
so many universities across the United
States, had developed many of its university A second driving factor for the consolidation
business processes around students’ SSNs of the directories was FSU’s creation of a
as identifiers (e.g., for tasks such as university-wide CIO position. At the time the
registration, grading, financial aid). As these CIO position was created, the two LDAP
business processes continued to evolve, directories mirrored the duality in FSU’s IT
especially towards web-based access, they support structure. One LDAP directory and
offered many enhancements to the end- organizational IT entity supported academic
user. However, the need to insure the computing, while the other directory and IT
privacy and security of users that were entity supported administrative and business
accessing applications that contained computing. When the two IT support groups
confidential financial or personally identifying were placed under the purview of the new
information was becoming more critical. IT CIO, their separate LDAP directory projects
management and technical staff became were tagged for integration as well.
acutely aware not only of the need for SSO, However, that merger would be preceded by
but to provide a new mechanism to a best of breed enterprise directory
authoritatively determine identity. “competition” between the LDAP1 and the
LDAP2 project developers and managers
Concurrent with these challenges of the late that continued until the 2000 to 2001
1990s, FSU was also analyzing and testing timeframe.
two Lightweight Directory Access Protocol
FSU: Identity Management & NMI-Component Integration 6
NMI Integration Testbed Case Study Series January 2005the NMI-EDIT2 Consortium, the Testbed
Influence of Internet2 and
consists of eight universities that participate
the NMI Integration Testbed
in a closely coordinated effort to deploy and
By the spring term 2002, FSU had fully
evaluate NMI technologies. Participation as
deployed the academic LDAP1 with
an NMI Testbed site enabled FSU to
Blackboard. Following this deployment, the
continue to build upon its body of knowledge
central IT organization established a joint
in middleware through the systematic
Directory Services Team (DST) whose
evaluation and review of NMI Releases and
primary focus was to bridge or integrate both
LDAP directories, thus providing a policies.
centralized authentication service for the
campus. Working in the NMI Integration Testbed with
NMI tools not only helped FSU build their
When the DST set about planning for institutional knowledge more quickly than
integration of the LDAP directories, they they likely would’ve by working alone, it also
used the information provided by Ken provided FSU with significant information on
Klingenstein, Director of the Middleware where they stood in the deployment of an
Initiative for Internet 2, who had visited the Enterprise directory service. In addition, the
university in the fall of 2001 During his visit, collaborations and communications between
Klingenstein presented FSU staff with all members of the NMI Integration Testbed
valuable information about identity contributed to FSU’s decision to integrate
management and a variety of other the directory architecture with FSU’s
technology issues common to the higher ERP/PeopleSoft implementation that
arena. Klingenstein’s visit helped jumpstart replaces their previous HR and Financial
FSU’s concerted efforts to deploy a new, “home grown” systems.
consolidated LDAP architecture on campus.
NMI Components
FSU found various NMI-EDIT tools reviewed
FSU also took advantage of a unique
in the Testbed project particularly relevant to
opportunity that allowed them to reduce the
their identity management and directory
developmental and research time needed to
services project:
deploy their directory service. In June 2002, 3
• NMI-EDIT’s eduPerson directory schema
FSU began participating in the National
• NMI-EDIT’s middleware Conventions and
Science Foundation (NSF) NMI (NSF
Best Practices4, LDAP Recipe5 and
Middleware Initiative) Integration Testbed.
Managed by the Southeastern Universities
2
NSF Middleware Initiative-Enterprise and Desktop
Research Association (SURA) on behalf of Integration Technologies (NMI-EDIT): http://www.nmi-
edit.org/
3
eduPerson information:
http://www.educause.edu/eduperson
4
Conventions and Best Practices:
tp://middleware.internet2.edu/dir/
FSU: Identity Management & NMI-Component Integration 7
NMI Integration Testbed Case Study Series January 2005Metadirectory Best Practices6 “real world” examples of metadirectories
The eduPerson directory schema was a key integrated with Microsoft’s Active Directory
enabler for FSU in their implementation to draw from, FSU found the practical
process. They found that the eduPerson recommendations and discussion of groups
schema provides a strong standard and and metadirectories in the LDAP Recipe to
base that any organization can use to be very helpful.
populate their metadirectory. This is true
whether the institution is just starting a
Need for a Vendor Solution
metadirectory, or already has a mature As noted, FSU had been providing
metadirectory. FSU extended the eduPerson centralized academic computing and
schema by creating the “FSUperson”. network access to an on-line public directory
Additionally, right “out of the box”, FSU and e-mail services for many years. Their
found eduPerson enabled them to do inter-
deployment of Blackboard and other web-
institutional authentication.
based applications added to the complexity
of their authentication and authorization
The Metadirectory Best Practices document, environment, as did concerns about the use
one in the series of NMI-EDIT’s Conventions of SSNs as identifiers. Over a two-year
and Best Practices documents, provided timeframe, they had also deployed a
FSU with validation of the path they had directory service layer comprised of LDAP
already undertaken for the use of groups directories 1 and 2 (primarily done using
and group roles. This document includes
iPlanet’s Netscape directory service product
discussion of the how to use groups and
and Microsoft’s Active Directory services).
group roles in a directory structure. Another
The directory service layer was a critical
key factor in the metadirectory structure is to component for integrating the two previously
keep the naming conventions within the OU standalone directory services as it provided
(Organizational Unit) flat, that is, not to the “authoritative source” directory required
create a deeply tiered hierarchy. for an identity management solution. The
layer enabled campus-wide connectivity to a
Finally, since the merging of their two FSU new secure, centralized directory service
LDAP directories was a key step in their
that provided enterprise-wide authentication
total solution, FSU also used the LDAP and authorization.
Recipe as a tool in their identity
management and metadirectory The Directory Services Team (DST) worked
deployment. While FSU would’ve liked more for at least seven months to create a bridge
5
“A Recipe for Configuring and Operating LDAP
in the campus directory service layer
Directories” available at:
between the academic and administrative
http://www.duke.edu/~gettes/giia/ldap-recipe/
6
Metadirectories Best Practices information: services LDAP directories that comprised
http://middleware.internet2.edu/dir/metadirectories/inter
net2-mace-dir-metadirectories-practices-200210.htm
FSU: Identity Management & NMI-Component Integration 8
NMI Integration Testbed Case Study Series January 2005the campus’s directory service layer. • FSUcard- Each on-campus faculty,
However, the DST team didn’t have student and staff is issued a “smart card”.
sufficient resources to complete their work Both the LDAP1 and the LDAP2 use the
“in-house”. The dedicated internal resources FSUcard number as an identifier for
the integration required were simply not authenticationii.
available, due to the university’s • Computer Account Registration System
reprioritization of IT initiatives. Resources (CARS)- This “home grown”
had been shifted away from the DST’s authentication domain system handles
centralized authentication initiative and some 50,000 accounts for students,
redirected to a new campus initiative for the faculty and staff. The source for accounts
selection and implementation of (by July includes data from Human Resources and
2004) an Enterprise Resource Project. the FSUcard system. The information is
reflected in the LDAP1 server.
Thus mid-year 2003, FSU’s IT leaders • On-line Personal Services/Secure Login-
reached a conclusion that it would take This “home grown” system handles some
years and significant recurring funding to 100,000 accounts for students, faculty
achieve full deployment, unless at least and staff. The source for accounts
seven or more full- or three-quarter- time includes the HR and the FSUcard system,
technical personnel were dedicated to the as well as legacy databases. The
integration endeavor. At this critical juncture, information is reflected in the LDAP2
the decision was made to retain an outside server. Users authenticate into Secure
vendor that would provide consulting, Login by using their FSUcard, self-
software and maintenance support services selected “Webname” or SSN.
as a key part of FSU’s campus-wide • Northwest Regional Data Center
deployment of an integrated, secure (NWRDC) login IDs- The NWRDC houses
directory service and identity management most of the FSU enterprise administrative
protocol. information. The SSN/PIN system table is
used as an older-style of web
Complex Needs
authorization. Many Java-based
IT leaders analyzed their options for an
applications use NWRDC accounts as
enterprise-level metadirectory solution that
well.
would provide the provisioning of data from
• FSU Active Directory tree- A cluster of
the metadirectory to other services and
i
Windows 2000 machines provide
applications. They developed an inventory
Microsoft Exchange, authentication and
of the major enterprise-wide applications
file service to approximately 4,000
within the University that would need to
administrative users on campus. A
connect to the new FSU metadirectory
number of mail domains are serviced
solution:
within this tree.
FSU: Identity Management & NMI-Component Integration 9
NMI Integration Testbed Case Study Series January 2005• Novell Netware/eDirectory- A number of • LDAP directories
Novell servers provide network drive • Active Directory clusters
space for approximately 4,000 • Self-service academic and business
administrative users on campus. applications and their related databases
• Emerging PeopleSoft ERP system - FSU • ERP/PeopleSoft software
is replacing its HR and Financial “home • Data warehouse
grown” systems with PeopleSoft.
Authentication for the PeopleSoft system Furthermore, the vendor-provided solution
is expected to leverage the existing LDAP needed to satisfy the following functional
directories or perhaps create another requirements:
LDAP directory that contains a populated • The identity management schema had to
schema. be extensible and expressed as an
• Prototype Portal- This test portal extension to the eduPerson schema, with
manages the illusion of merging eduPerson fields populated.
authentication requests from the LDAP1 • Identity management tools had to be
or the LDAP2 using an instance of Yale’s scriptable, and provide an API
CAS (Central Authentication Service) (application program interface).
server. • Code and examples for password
• Additional “pockets” of enterprise synchronization needed to be included.
authentication- Smaller systems relying • Single sign-on (SSO)/initial sign-on (ISO)
on local authentication include Remedy, needed to be included.
iii
SEVIS, Business Objects and C.O.L.D. • The solution needed to support the move
• FSU Departmental servers- A number of away from using SSN as an identifier
FSU departments have large enough within the various systems and be able to
populations and expertise that they have handle visitor accounts with limited
their own authentication domains. Some access and/or duration.
are connected to the FSU Active Directory • The solution needed to support the
forest, while others run a variety of integration of two iPlanet 5.1 directories
heterogeneous environments. (LDAP1 and LDAP2), Active Directory,
PeopleSoft, Kerberos 5, NDS, and
Blackboard.
The Vendor Solution
• The solution needed to provide a
RFQ Specifications
standards-based tool for writing
The vendor selected through FSU’s RFQ
bridge/interface APIs to handle fits/gaps
process had to provide an open-standards,
identified within the existing and future
secure services-/application-provisioning
enterprise metadirectory service
solution that enabled the enterprise
architecture (including connectivity to
integration of the following:
existing e-mail applications and non-
FSU: Identity Management & NMI-Component Integration 10
NMI Integration Testbed Case Study Series January 2005• LDAP directory services, as well as languages (PHP, PAM, and C desirable).
standards-based portal solutions.) Applications that were anticipated to use
• The solution needed to include a web ISO Web ISO from the metadirectory included
system with ability to authenticate IIS and CARS, Secure Login, Blackboard,
Apache, and provide an API for at least PeopleSoft, Portal solution, NDS and
the Java and Mod-perl programming Active Directory.
Vendor Selection
Using these specifications to evaluate enterprise directory design7 (Fig. 1) is
vendor proposals, FSU selected Novell’s reflected in FSU’s design architecture, which
eDirectory product. Novell was the clear is customized to fit the FSU environment
choice, as only Novell met FSU’s specific and includes the NMI-compliant Novell
RFQ criterion for a solution that would also eDirectory solution and FSU’s PeopleSoft
integrate with FSU’s ERP/People soft deployment (Fig. 2).
implementation. The NMI-EDIT standard
7
http://www.nmi-edit.org/roadmap/dir-
roadmap_200505/design/design-set.html
FSU: Identity Management & NMI-Component Integration 11
NMI Integration Testbed Case Study Series January 2005Implementation Chronology Project Integration of
Novell’s consultants worked in partnership
Person Identifiers
with FSU’s metadirectory team to bring up Concurrent with the rollout of the eDirectory,
the metadirectory in a lab environment. The FSU IT leaders have implemented an active
entire project timeline was delineated in project to migrate FSU’s departmental
FSU’s identity management RFQ as well as business processes and software away from
in the ERP/PeopleSoft project management the use of SSNs wherever possible. The
plan. The projects proceeded as follows: development of two new person identities for
use in the new eDirectory infrastructure
• Analysis and Design – November 2003
provides the means by which this migration
through March 2004. is being conducted.
• Laboratory testing – March through mid-
June 2004. The "private" use of SSNs will be replaced
• Production w/ERP – June 18, 2004.
by new "FSU Security Numbers"
• ERP financials, purchasing – July 1,
(FSUSNs)iv. Private use situations occur
2004.
when an individual (student, employee, etc.)
must prove their identity to an agent of the
university (HR person, student service
FSU: Identity Management & NMI-Component Integration 12
NMI Integration Testbed Case Study Series January 2005employee, etc.). The second situation where
Challenges Met
SSNs have historically been used at FSU is As of Fall 2004, the Novell eDirectory
termed “public" or "semi-public" use to software had been deployed on five
uniquely identity individuals in a list. For production servers located strategically
example, a typical list of students by SSN across campus, providing redundancy and
might have been used for various reports in fault tolerance. The schema for this directory
FSU’s Housing, Registrar, and academic servicev includes key fields from the original
departments. As part of the SSN migration two competing LDAP directories and a
project, the public/semi-public use of SSNs variety of additional attributes that serve new
will be replaced by individual FSUIDs. The functions. The eDirectory now provides the
FSUID is "public" in the sense that it can be following services for basic authentication
used on reports to uniquely identify one and authorization:
person from another. • Password synchronization for a growing
list of FSU identities, including ACNS
These situational usage guidelines are (Academic Computing and Network
assisting FSU departments in making Services) /garnet/mailer accounts, Secure
correct choices about how and when to use Login/OPS accounts, Outlook Exchange
person identifiers. The ability for any accounts within two Active Directory
particular department to implement their new trees, and the newly minted "FSUID"
person identifier business process with their account.
business application software has been • Centralized, coherent identity
made possible by the thoughtful design management tied to a single web
decisions FSU’s IT leaders made during the location8 for all electronic identities at
rollout of the new eDirectory. The FSU.
eDirectory/FSUID application has been • Extensive background of automated
designed to be the key delivery method for "feeder scripts" that keep the attribute
FSUSNs to individuals. The FSUID login values up to date. The schema currently
name and password will be used to stores the typical directory information as
authenticate people to the ERP/PeopleSoft well as current data skimmed from the
system and ties together the major appropriate locations in the Student
enterprise-wide existing identities (e.g., Information System (SIS) and HRMS
CARS/ACNS/Blackboard, Secure Login, systems. This includes, for example,
Outlook, PeopleSoft) into a new SSO name current semester class schedules.
and password. • Integration with key departments
interested in having their local department
identities merged into the eDirectory in an
8
http://fsuid.fsu.edu/
FSU: Identity Management & NMI-Component Integration 13
NMI Integration Testbed Case Study Series January 2005appropriate fashion that allows retaining • Rollout of the FSUSN (SSN replacement
of autonomy. private identity).
• PeopleSoft production and test instances • Continual upgrades/upkeep of the
of Financials, Portal, and HR. hardware and software environments.
• A number of RADIUS servers used for
VPN authentication. Novell’s NMI-compliant eDirectory provides
• New eDirectory-based public search FSU option of implementing other NMI
9
engine technologies in the future. FSU will
• Subsuming of "legacy" LDAP servers by investigate NMI-EDIT’s Shibboleth® 10
converting the systems that use them to software, an open-source, standards-based
use the eDirectory in a native fashion. tool that provides mechanisms for controlling
Secure Login was implemented in access to web based resources (particularly
October 2004 and phasing out of the in inter-institutional environments) while
Human Resources Management System offering options for protecting personal
(HRMS) will take place on July 1, 2005. privacy. A related technology, “PKI” or
• Implementing a new computer Helpdesk Public Key Infrastructure, will also be
application that allows authorized investigated (PKI provides standards and
Helpdesk staff to look up and assist users services that facilitate the use of public-key
with account management. cryptography). Additionally, the FSUID
directory readies FSU to reach out beyond
the institution through the population of NMI-
FSU Identity Management
EDIT’s eduPerson fields.
and the Future
The FSU identity management project now
has a life of it's own, with the equivalent of More Information
two full-time employees dedicated to For more information about FSU’s identity
continued support and development. Future management solution, contact Joe Lazor at
efforts will concentrate on: JLazor@admin.fsu.edu.
• Removing the legacy LDAP directories.
References:
• Inviting more departments to connect their
(1) “SSN Replacement Principles- A
identities to the enterprise directory.
Strawman Proposal”.
• Web SSO through the Yale-developed
http://fsuid.fsu.edu/admin/ssn.html
CAS server with FSUID, Blackboard,
Secure Login and ACNS/CARS.
• Merging in the enterprise Novell Netware
identities.
10
Shibboleth information:
9
http://fsuid.fsu.edu/search http://shibboleth.internet2.edu/
FSU: Identity Management & NMI-Component Integration 14
NMI Integration Testbed Case Study Series January 2005Links of Interest
Florida State University (FSU) www.fsu.edu
FSU authentication domain http://campus.fsu.edu
FSUcard http://fsucard.fsu.edu
FSU Computer Account Registration System (CARS) https://cars.acns.fsu.edu/
FSU eDirectory http://fsuid.fsu.edu/admin/metadir_project.html
FSU PeopleSoft ERP system http://www.aim.fsu.edu
FSU Prototype Portal http://uportal.fsu.edu
GRIDS Center http://www.grids-center.org/
NMI-EDIT http://www.nmi-edit.org/
NMI Integration Testbed Program http://www1.sura.org/3000/NMI-Testbed.html
Novell eDirectory http://www.novell.com/products/edirectory/
NSF Middleware Initiative http://www.nsf-middleware.org/
NWRDC login IDs http://nwrdc.fsu.edu
On-line Personal Services/Secure Login https://apps.oti.fsu.edu/servlet/login
Yale’s CAS Server http://tp.its.yale.edu/tiki/tiki-index.php?page=CentralAuthenticationService
i
More technical detail about these applications is available at:
fsuid.fsu.edu/admin/metadir/FSUMetaDirRFQ.doc
ii
The schemas used on LDAP1 and LDAP2 were not the same, nor was the information stored in the
schemas (they use different domain names, for example). Most people have an LDAP1 and an LDAP2
entry that are, for the most part, equivalent. Some name collisions and omissions exist.
iii
Remedy – Remedy Ticketing system (Remedy accounts and a local Oracle server). SEVIS – a student
tracking system. Business Objects – an on-line report generating tool that uses it’s own proprietary
authentication system. (http://buso.oti.fsu.edu/). C.O.L.D. – store print files onto disk, own proprietary
authentication scheme (replicates NWR “fs” accounts). (http://www.docfinity.com/).
iv
Project principles for FSU’s migration away from the inappropriate use of SSNs to new FSUSNs are
detailed at http://fsuid.fsu.edu/admin/ssn.html
v
The schema for FSU’s Novell eDirectory service is documented at http://fsuid.fsu.edu/cgi-
bin/attributes/fsuid-schema.cgi
FSU: Identity Management & NMI-Component Integration 15
NMI Integration Testbed Case Study Series January 2005You can also read
