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

System Administration - Extending & Integrating Signet

Extending Signet

1. Adding your institution's logo to the default UI
2. Modifying demo and training materials
3. UI Stylesheet modifications, for overall changes to colors, fonts, button styles, etc.
4. Adding new limit types and behaviors via Struts Tiles
5. Modifying Signet itself

1. Adding Your Institution's Logo to the Default UI

A standard location in the upper left-hand corner of each page of the UI has been set aside for the simplest form of institutional branding – the addition of a logo that identifies your site and your instance of Signet. The Signet-QuickStart version and Signet Demo site use the fictitious educational institution "Kern Institute of Technology, Northam", KITN for short, whose logo is shown here. It shows an ideal 60-pixel height, while the width (158 pixels) can more easily vary.

Default blank image:
Demo logo:

Replace the following file with the image of your choice:

signet/webapp/signet/images/site-logo.gif

2. Modifying Demo and Training Materials

The Signet-QuickStart version provides a useful demo environment. As installed, it contains fictitious people and realistic, yet abstract, demonstration privileges. This version can be updated to have a site-specific logo, to load local person information, and may be used to test and demonstrate your own local privilege management designs.

Coming soon: additional training material will follow with subsequent releases of Signet; contact us.

3. UI Stylesheet Modifications

The overall look and feel of the Signet UI is governed by a style sheet located at signet/webapp/styles/signet.css in the distribution.

4. Adding New Limit Types and Behaviors via Struts Tiles

The UI is built in part using Apache Struts "tiles", which defines sections of the screen as independent modules that can be changed independent of the rest of the application. The functionality exists in Signet 1.0, but the API has not yet been formalized and released for specific use, such as for implementing a custom Limit with associated screen processing. Contact us for more information on this capability.

5. Modifying Signet Itself

Signet is an open source project that works with higher education community developers to evolve the capabilities of the product. If you have special needs beyond the capabilities of Signet, or would like to contribute to its development, look here.

Integrating Signet with Your Enterprise Infrastructure

• Inputs – data that Signet needs in order to interact with users and to manage their privileges, and
• Outputs – delivery of privilege information to applications, where it is then applied

Inputs

Signet needs to know about three kinds of enterprise data:

• People – who are your users; those that can login as well as those that can be assigned privileges,
• Groups – multiple people managed as a named set of individuals, and
• Organizations – information about your organizational structure, for scoping privilege assignments.

Signet can know of these data in two ways:

• Data can be periodically loaded into internal tables through administrative utilities (see the System Administration section on the Documentation page). This is the only method available for organization data. Bear in mind that people and groups are far more dynamic than organizations, so this method requires a strategy to keep the information in Signet up-to-date.
• Information about people and groups can be accessed through a site-developed interface using the Subject interface. This is done using a "Subject Source Adaptor" in Signet. See the section on Source Adaptors below.

Outputs

Signet currently has one form of output – a <Permissions> XML document, which an application may read to determine privileges held by an individual. A "provisioning connector" program is needed to translate Signet Permissions into the security for your application or service. This can be straightforward, if you have a well-defined security model and have also defined simple Privilege-to-Permissions mapping in the design of your Signet privileges. As a piece of local software, it can be as sophisticated as needed to implement security, based on Signet information.

Coming soon: Sample code and suggestions as to how your institution can best meet this need. More information will be available at the upcoming Early Adopters Signet/Grouper Deployment Workshop (since past, please see the wiki for latest updates); please contact us if you need assistance before this section is updated.

Subject Source Adaptors

The Signet toolkit has a strategy for interfacing with external data sources through the use of a neutral interface, isolating Signet itself from particulars of where external data resides and how it is accessed. An adapterClass in Signet is a JAVA implementation of such an interface to connect Signet with a particular source of information.

Signet v1.0 supports the use of adaptor classes for accessing Subject information, using the Internet2 Subject API [ref. to draft specification]. In addition, the Signet schema defines tables where information for each of the entities can be stored locally, in lieu of external sources that can be easily plugged in. Signet v1.0 comes with a JDBC adapter class to interface with these local tables.

Here is the flow of data and control:

Other adapter implementations are possible for any entity – Signet plans to provide an LDAP implementation to connect to a directory source of eduPerson information. By defining appropriate adapter classes, an institution can connect with any appropriate source of data. A source adaptor class needs to be developed for use to meet new situations, but once developed they can be reused in multiple subsystems or shared with other Signet sites.

Once developed, the existence of each adaptor class is declared in the sources.xml file within Signet:

• signet/util/classes/sources.xml

• signet/webapp/signet/WEB-INF/classes/sources.xml

Multiple sources can be used, each declared as a separate <source...> instance in this file. The pre-defined local subject source adaptor declaration is shown here:

<sources>

  <source adapterClass="edu.internet2.middleware.subject.provider.JDBCSourceAdapter">
    <id>local</id>
    <name>Local Subject Source</name>
    <type>person</type>
    <type>group</type>
        :
      

Each is also configured with appropriate runtime connection information. The Database parms are shown here:

    <!-- Database connection properties -->
    <init-param>
      <param-name>dbDriver</param-name>
      <param-value>@DB_DRIVER@</param-value>
    </init-param>
    <init-param>
      <param-name>dbUrl</param-name>
      <param-value>@DB_URL@</param-value>
    </init-param>
    <init-param>
      <param-name>dbUser</param-name>
      <param-value>@DB_USERNAME@</param-value>
    </init-param>
    <init-param>
      <param-name>dbPwd</param-name>
      <param-value>@DB_PASSWORD@</param-value>
    </init-param>