[Home] [About] [FAQ] [Software] [Documentation] [Contact]

System Administration - Running & Supporting Signet

Running Signet

Signet, as delivered, provides a functioning core web-based UI that needs to be made a part of the local environment. Every attempt has been made to make it amenable to a variety of deployment options commonly in use at Higher Ed institutions, but final decisions on where and how Signet is run can only be made by the support staff at your site. You will need to read and understand the Phase I – Prerequisites/Preparations section of the Installation & Deployment guide to understand the basic requirements for installing Signet.

• Installation

  The Signet System Administrator is responsible for initial installation and applying later updates to the product. See the Installation & Deployment guide for more information.

• Authentication

  A production Signet needs to be tied into your campus authentication and security, presumably through a Web single-signon system, e.g., some form of WebAuth, PubCookie, or other similar schemes. Signet only requires that the environment, in which it runs, provides a value in REMOTE_USER; doing this securely will vary site to site.

• Customization

  Signet, out of the box, is a generic application with a default Internet2 look and feel. Part of deploying Signet will be to determine the extent to which Site customization will be required. This could affect how the product is laid out and built at a site. See the Extending & Integrating guide.

• Integration

  Signet integrates with an enterprise's infrastructure through a type of code login called adaptors. These may require local development, and then they need to be added to the deployed product and referenced through metadata. Signet provides a reference implementation of one such adaptor, but the work is not yet finished, pending the completion of the Internet2 Subject specification. Contact the mailing list for more information.

Supporting Signet

The Signet System Administrator is responsible, likely collaborating with others, for the smooth functioning of a Signet application. Beyond the simple installation and running of the software, there are additional Signet-specific responsibilities in supporting the service over time:

• Loading Organization Data

  Signet privileges can reference organizational "scope", basically which department, school, or other organizational entity of which a specific privilege assignment is a part. While the data itself is institutional information and requirements for this data will come from the applications that define Signet privileges, a Signet Administer may be required to render the data into an XML input format, and load the data into Signet's Tree table, refreshing that data periodically.

  See utility scripts under /signet/util/TreeXmlLoader.

• Designating Subsystem Owners

  Subsystem Owners are those people working on behalf of an organization, application, or service that is defining and managing privileges through Signet. A Subsystem owner must be designated within Signet to enable him or her to assume online responsibilities for a given subsystem. See the Signet Roles & Internal Privileges document for more information.

  See utility scripts under /signet/util/SignetProxy.

• Support for Subsystem Owners

  Subsystem Owners have a lot of autonomy online to perform their tasks, but will need assistance for anything supported by a utility program outside the UI. The one item currently in this category is the loading of Subsystem definitions.

  See utility scripts under /signet/util/SubsystemXmlLoader.

• Support for Subjects

  A Subject adaptor might connect Signet dynamically to an enterprise source of person data. If not, regular Person data loads may be required. See the Extending & Integrating document for more information about integration components and details on how to load Person data into a local Subject

  See utility scripts under /signet/util/SubjectFileLoader.

• Lifecycle

  Signet provides "lifecycle" support for the automatic activation and deactivation of privileges. A small script should be run nightly to detect effective and expiration date changes and to process the affected assignments. A sample script is located in /signet/util/AssignmentReconcile.