Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The Insight User Manager currently supports three Security Models. By default, Insight is configured with the standard security model which simply uses the usernames and passwords in the User Manager. Since Insight 4.1, Luna has modularized the methods that Insight uses to manage Authentication and Authorization. Luna has also released two new security modules for those institutions that are interested in configuring Insight to work with an existing security provider.

Pure LDAP

The first security module out-sources the process of Authentication to an LDAP Server. To use this module, you must first have an LDAP Directory Server that supports LDAP v3. The following are LDAP Servers that Luna has tested against:

    • Windows 2000's Active Directory server
    • OpenLDAP
    • SunONE Directory Server v5.2

NOTE: Insight optionally supports SSL connections for LDAP Queries.

Kerberos & LDAP or (Windows® Active Directory)

The second security module out-sources Authentication to a Kerberos 5 Server and Authorization to an LDAP Server. To use this module, you must have a working Kerberos 5 implementation and an LDAP Server that supports GSS-API SASL. The following implementations have been tested:

    • Windows 2000's Active Directory Server (provides both Kerberos & LDAP)
    • MIT Kerberos 5 KDC with one of the following:
      • OpenLDAP
      • SunONE Directory Server v5.2

NOTE: Insight optionally supports SSL connections for LDAP Queries.

Enabling Simple LDAP Authentication for the Insight User Manager

NOTE: Changing Insight's Security model can have major repercussions. Please consult with your network and security administrators before implementing any changes regarding your local security environment.
NOTE: Please read and complete the Insight Security Worksheet at the end of this chapter before going any further.
NOTE: Finally, please test all configurations on a test server before implementing in a production environment.

  1. In a text editor, open the InsightUserServer.dat file located in the "<insight_install>\user_manager" directory.
  2. Change the Insight Authentication Handler to use LDAP:


    1. Locate the following lines:


      1. AuthenticationHandler - the full class name of the # authentication handler to use for authentication.
        AuthenticationHandler = com.luna.insight.client.security.DefaultAuthenticationHandler
    2. Change the AuthenticationHandler property to: com.luna.insight.client.security.SimpleLDAPAuthenticationHandler. This will tell the User Manager to use LDAP when authenticating users.


  1. Change the Authorization Handler to use LDAP:
  2. Locate the following lines:


      1. AuthorizationHandler - the full class name of the # authorization handler to use for authorization.AuthorizationHandler = com.luna.insight.client.security.DefaultAuthorizationHandler
  2. Change the AuthorizationHandler property to: com.luna.insight.client.security.SimpleLDAPAuthorizationHandler. This will tell the User Manager to use LDAP when authorizing users.
  3. Define the URL for the LDAP v3 Server:
  4. Locate the following lines:
      1. LdapURL - The URL of the LDAP server.# (note: under Windows 2000/Active Directory, this is the # address # of the Active Directory machine pre-pended with # ldap:// )#LdapURL = ldap://ldap.lunaimaging.com
  2. Uncomment the LdapURL property and change it to match the URL for your LDAP Server. When done, it should look like this:
      1. LdapURL - The URL of the LDAP server.# (note: under Windows 2000/Active Directory, this is the # address # of the Active Directory machine pre-pended with # ldap:// )LdapURL = ldap://your.ldap.server.edu
  2. Define whether insight should use SSL to communicate with the LDAP Server:
  3. Locate the following lines:
  1. LoginSSL - A value of 1, yes, or true, will cause LDAP # communication to use SSL. The LDAP server must be # configured to use SSL. Any other value (with 0 being the # correct one), or not specified, and LDAP communication # will not be secured.
  2. LoginSSL = 0
  3. Uncomment and change the LoginSSL property to 1. When done, it should look like this:
  1. LoginSSL - A value of 1, yes, or true, will cause LDAP # communication to use SSL. The LDAP server must be # configured to use SSL. Any other value (with 0 being the # correct one), or not specified, and LDAP communication # will not be secured.LoginSSL = 1
  2. Define the LDAP User Path – this is the directory path in the LDAP Server identifying where to find valid users.
  3. Locate the following lines:
      1. LdapUserPath: Directory path in the LDAP server # identifying object containing authenticatable users.
        LdapUserPath = ou=people,dc=lunaimaging,dc=com
  2. Uncomment the LdapUserPath property and set it to the path in the LDAP database that Insight should use to find valid users. When complete, it should look like this:
      1. LdapUserPath: Directory path in the LDAP server # identifying object containing authenticatable users.
        LdapUserPath = ou=people,dc=lunaimaging,dc=com
        NOTE: Search more the one "ou" in LDAP (new in 6.2).
        OPTIONAL SIMPLE LDAP CONFIGURATION: SEARCHING MULTIPLE BRANCHES IN THE DIRECTORY
        LdapUserPathN and LdapUserAttributeN: To grant Insight access to users distributed through
        more than one branch in a directory server, define additional LdapUserPath properties.
        Each additional LdapUserPath property must end with a unique integer greater than or equal to 2.
        In most configurations, the attribute used to identify user login names will be the same
        in all branches of the directory server. If this is not the case, you may define additional
        LdapUserAttribute properties, using the same numeric suffix technique.
        When a user logs in, Insight will search the directory server using search paths in numeric order.
        Example 1 – Search two paths, using the same user attribute:
        LdapUserPath = ou=professors,dc=myschool,dc=edu
        LdapUserPath2 = ou=catalogers,dc=myschool,dc=edu
        LdapUserAttribute = uid
        Example 2 – Search two paths, using a different user attribute for each:
        LdapUserPath = ou=professors,dc=myschool,dc=edu
        LdapUserAttribute = uid
        LdapUserPath2 = ou=catalogers,dc=myschool,dc=edu
        LdapUserAttribute2 = login
  2. Define the LDAP User Attribute – this is the field that usernames are authenticated against.
  3. Locate the following Lines:
      1. LdapUserAttribute - LDAP Attribute to match usernames# against. # Examples: # LdapUserAttribute = cn // Active Directory# LdapUserAttribute = uid // LDAP using EduPerson schema
        #LdapUserAttribute = uid
  2. Uncomment the LdapUserAttribute and set it to the field in your LDAP Database that contains usernames. When complete, it should look like this:


      1. LdapUserAttribute - LDAP Attribute to match usernames# against. # Examples: # LdapUserAttribute = cn // Active Directory# LdapUserAttribute = uid // LDAP using EduPerson schema
        LdapUserAttribute = uid

        Associating LDAP Users with Insight Users

        Each User in the Insight User Manager will be matched with an LDAP user by comparing the username properties. Usernames must be unique for this authentication model to work properly. Please also ensure that passwords are populated although these passwords are not used for authentication. The passwords will be validated through the LDAP Query.

        Using LDAP SSL Certificates with Insight

        Secure Socket Layer (SSL) Communications require a certificate to encrypt data during transit, as well as to prove the identity of each party involved. For public use, trusted certificate authorities (i.e. Verisign, Thawte) provide trusted SSL certificates. Insight's LDAP Authentication method will automatically recognize and support Verisign & Thawte SSL Certificates.

        Kerberos & LDAP Authentication and Authorization

        NOTE: Changing Insight's Security model can have major repercussions. Please consult with your network and security administrators before implementing any changes regarding your local security environment.
        NOTE: Please read and complete the Insight Security Worksheet at the end of this chapter before going any further.
        NOTE: Finally, please test all configurations on a test server before implementing in a production environment.

        Kerberos Authentication - Overview

        Kerberos Version 5 is used for both the authentication and secure communication aspects of the Luna client and server applications. In order to use the Kerberos authentication method, you will need access to a Kerberos installation. To configure the Insight User Manager, you will need the default realm and the default KDC of your Kerberos installation. Contact your network administrator responsible for the Kerberos server for these configurations.
        As with all Kerberos installations, a Kerberos Key Distribution Center (KDC) is required. It needs to contain the user name and password you will use to be authenticated to Kerberos. Note: A KDC implementation is part of a Kerberos installation, not a part of the Insight installation.
        The essential Kerberos configuration information is the default realm and the default KDC. Typically, the default realm and the KDC for that realm are indicated in the Kerberos krb5.conf/krb5.ini configuration file. On Windows, the krb5.ini file can be located in c:\winnt\. On Unix, the file is located in the \etc\ directory. If this file does not exist or you are unsure of the configurations, contact your network administrator responsible for the Kerberos server for these settings.
        To minimize client configuration requirements, Insight provides a version of the Kerberos configuration file to each Insight client when Kerberos authentication is used. This file is written to the application's installation directory and has no impact upon the krb5.conf/krb5.conf file that may or may not reside on your system. Insight uses this file for the default realm and default KDC information. These values are defined in the InsightUserManager.dat file located in the Insight User Manager sub-directory.

        Specifying the Kerberos Settings


  2. In a text editor, open the InsightUserServer.dat file located in the "<insight_install>\user_manager" directory.


  1. Define the KerberosRealm property. This is the default Kerberos realm to which the user will be authenticated. This Kerberos Realm will be attached to the user ID's for authentication. The Kerberos Realm must be defined in ALL CAPS. (e.g. KerberosRealm = LUNAIMAGING.COM).


  1. Define the KerberosServer property. This is the default Kerberos Key Distribution Center (e.g. KerberosServer = kerberos1.lunaimaging.com).


If you are unsure of these values, you may wish to submit the Implementation Worksheet to your system administrator responsible for Kerberos and Directory Services.
For example, say I was unsure of the default realm and default KDC used at my institution. After contacting my network administrator, he/she provides the following information:
Default Realm = LUNAIMAGING.COMDefault KDC = kerberos1.lunaimaging.com
With this information, I open the InsightUserServer.dat file located in the Insight User Manager installation directory. In this example, I define the KerberosRealm as LUNAIMAGING.COM. I also define the KerberosServer as kerberos1.lunaimaging.com. It is important to note that the Kerberos Realm is defined in ALL CAPS. Under Windows 2000/Active Directory, the Kerberos Realm is usually the same as the Active Directory domain name. On Solaris, the Kerberos Realm may or may not be the same as your domain, but conventions encourage using the domain name, in upper-case letters. In this example, members of lunaimaging.com are in the Kerberos realm LUNAIMAGING.COM.
KerberosRealm = LUNAIMAGING.COM KerberosServer = kerberos1.lunaimaging.com
Based on the example above, the krb_config.conf file created on the client's application installation directory would contain the following information:

      1. insight krb_config.conf file ###
        [realms]LUNAIMAGING.COM = { kdc = kerberos1.lunaimaging.com}[domain_realm].lunaimaging.com = LUNAIMAGING.COM### end insight krb_config.conf file ###

        Enabling Kerberos Authentication for the Insight User Manager

        In order to enable the Kerberos Authentication Handler, in the InsightUserServer.dat file, modify the AuthenticationHandler property to reference the KerberosAuthenticationHandler instead of the standard Insight DefaultAuthenticationHandler. Save changes and restart the Insight User Manager.
        For example, the AuthenticationHandler property should appear as below:
        AuthenticationHandler = com.luna.insight.client.security.KerberosAuthenticationHandler
        If you wish to later re-enable the standard Insight User Database authentication method, simply replace the line above with "AuthenticationHandler = com.luna.insight.client.security.DefaultAuthenticationHandler". Save changes and restart the Insight User Manager.

        LDAP Authorization - Overview

        LDAP (Lightweight Directory Access Protocol) is a software protocol for enabling individuals and applications to locate information about organizations, individuals, and other resources. In the case of Insight, the LDAP Directory is used to store Insight authorization information. Insight uses the Kerberos credentials obtained during the Kerberos authentication process to gain access to the LDAP Directory Service. The use of Kerberos authentication by the LDAP Server unites the LDAP services with the Kerberos credentials and Kerberos based services. This also removes the need for Insight to ever store administrative passwords to the LDAP Directory service.
        The use of Kerberos credentials for LDAP Directory access requires an LDAP Server supporting the GSS-API SASL mechanism. The Generic Security Service API (GSS-API) provides a common interface for accessing different security services, such as Kerberos V5. Simple Authentication and Security Layer (SASL) is the mechanism used to authenticate against another service using existing Kerberos credentials. The GSS-API SASL mechanism is only supported by LDAP v3 Servers. The LDAP Servers that support the GSS-API SASL mechanism include Windows 2000's Active Directory Server, OpenLDAP, and the SunONE Directory Server v5.2.
        The use of an LDAP Server for Insight authorization requires the ability to assume the identity of the authenticated Kerberos principal. In other words, the Kerberos Principal Name provided during authentication must also be present in the LDAP Directory. For example, if your Kerberos principal name is jsmith@foobar.com, an attribute containing the value "jsmith@foobar.com" must exist in the directory.

        Specifying the LDAP Settings

  2. In a text editor, open the InsightUserServer.dat file located in the "<insight_install>\user_manager" directory.
  3. Define the URL for the LDAP v3 Server:
  4. Locate the following lines:
      1. LdapURL - The URL of the LDAP server.# (note: under Windows 2000/Active Directory, this is the # address # of the Active Directory machine pre-pended with # ldap:// )#LdapURL = ldap://ldap.lunaimaging.com
  2. Uncomment the LdapURL property and change it to match the URL for your LDAP Server. When done, it should look like this:
      1. LdapURL - The URL of the LDAP server.# (note: under Windows 2000/Active Directory, this is the # address # of the Active Directory machine pre-pended with # ldap:// )LdapURL = ldap://your.ldap.server.edu
  2. Define the LDAP User Path, this is the directory path in the LDAP Server identifying where to find valid users.
    1. Locate the following lines:
      1. LdapUserPath: Directory path in the LDAP server # identifying object containing authenticatable users.
        LdapUserPath = ou=people,dc=lunaimaging,dc=com
    2. Uncomment the LdapUserPath property and set it to the path in the LDAP database that Insight should use to find valid users. When complete, it should look like this:
      1. LdapUserPath: Directory path in the LDAP server # identifying object containing authenticatable users.
        LdapUserPath = ou=people,dc=lunaimaging,dc=com
  2. Define the field in the LDAP database that contains the Insight User Profile:
  3. Locate the following lines:

###TargetAttributeName - The LDAP attribute name which stores # the collection data/profile ID's needed by the # application.
#(note: in the case of Active Directory, "info" is the "notes" field under the "telephones" tab in a user's properties.)
#TargetAttributeName = info

  1. Uncomment and define the TargetAttributeName property. This is the LDAP attribute in which the Insight Access Profile may be found. This is the LDAP attribute name containing the Insight Access Profile needed for authorization. Insight requires the use of an LDAP attribute name, which stores the collection access information. For Windows 2000 Active Directory, by default, the "info" attribute is used. See the Windows® Active Directory & Insight User Account Information section of the documentation for additional details. For other LDAP Servers, you will need to determine which attribute is currently unused, or create a new attribute to store the Insight Access Profile.


  1. Define User metadata fields in the LDAP Directory.


  1. Locate the following lines:

###UserAttributeName - The LDAP directory attribute name under which the user's unique login name can be found.
#UserAttributeName = userprincipalname

  1. User Info Attributes - Added 2003-07-24
    #OrganizationAttributeName = company
    #EmailAttributeName = mail
    #PhoneAttributeName = homePhone
  2. Uncomment and define the UserAttributeName, OrganizationAttributeName, EmailAttributeName, and PhoneAttributeName properties. The User Attribute name is the LDAP attribute in which the full Kerberos name may be found. This attribute is used to uniquely identify the user when searching the LDAP directory. The values stored in this field MUST be of the form: <YOUR USERNAME>@<YOUR KERBEROS REALM>. For Windows 2000 Active Directory, this attribute will always be "userprincipalname". For OpenLDAP using the kb5-kdc.schema, this attribute will be the "krb5PrincipalName" (e.g. UserAttributeName = userprincipalname).The OrganizationAttributeName property is the LDAP attribute in which the user's organizational membership information is stored. Obtained values are used for administrative purposes within Inscribe. For Windows 2000 Active Directory, the "company" attribute is used to store this information. For OpenLDAP using the EduPerson schema, the "organizationName" attribute will typically be used. The EmailAttributeName property is the LDAP attribute in which the user's e-mail address information is stored. Obtained values are used for administrative purposes within Inscribe. For Windows 2000 Active Directory, the "mail" attribute is used to store this information. For OpenLDAP using the EduPerson schema, the "mail" attribute will typically be used. The PhoneAttributeName property is the LDAP attribute in which the user's telephone contact information is stored. Obtained values are used for administrative purposes within Inscribe. For Windows 2000 Active Directory, the "homePhone" attribute is used to store this information. For OpenLDAP using the EduPerson schema, the "telephonePhone" attribute will typically be used.

Enabling LDAP Authorization for the Insight User Manager

In order to enable the LDAP Authorization Handler, in the InsightUserServer.dat file, modify the AuthorizationHandler property to reference the LDAPAuthorizationHandler instead of the standard Insight DefaultAuthorizationHandler. Save changes and restart the Insight User Manager.
For example, the AuthorizationHandler property should appear as below:
AuthorizationHandler = com.luna.insight.client.security.LDAPAuthorizationHandler

Interaction of Kerberos & LDAP Users and Users in the Insight User Table

NOTE: Before enabling Kerberos & LDAP, please ensure that you delete all users from the Users tab in the Insight Administrator Tools. Maintaining existing users in the Insight User Manager introduces a potential security hole as clients that are not enabled for Kerberos & LDAP security will continue to try and authenticate using the Standard Authentication method.

Using the Insight Administrator Tool to identify Insight Access Profiles


  1. Launch the Insight Administrator Tools.


  1. Expand the User Manager node and connect to your default Insight User Manager.


  1. Click on the User Groups node. User Groups determine how users access collections.



  1. Identify the User Groups you want to be associated with an LDAP user account. For example, from the illustration above, ADMIN and PCDEFAULT will be used to associate with the user's LDAP directory entry. Multiple User Groups can be separated by commas.
  2. Click on the User Shares node. User Shares are places where end-users can save groups, presentations, or annotations.
  3. Identify the User Shares you want to be associated with the LDAP user account. In the example above "my share" will be used to associate with the user's LDAP directory entry. Multiple Shares can be separated with commas.
  4. Creating the LDAP string:
  5. Combine each of the User Group names, separating them with commas.
  6. For each User Share, define whether the user should have read, write, delete privileges.
  7. Combine each of the User Share Names with /w for read/write privileges. /wd for read / write / delete, or just the share name for read-only.
  8. Combine the Shares and privileges together, separating them with commas.
  9. Combine the list of all User Groups and all User Shares separating the groups with a colon. See example below:


UserGroup1,UserGroup2:UserShare1,UserShare2/wd
In this example above, the user has been given rights to access collections within UserGroup1, UserGroup2. The user also has read-only privileges to UserShare1, and read-write-delete for UserShare2.

  1. Populate the LDAP Insight Profile Attribute with the Insight Access Profile. For Active Directory follow the Windows Active Directory & Insight User Account Information section of this document. If you are using OpenLDAP, you will need to update the directory records through the OpenLDAP command-line interface. Consult your user documentation for details.

Windows® Active Directory & Insight User Account Information

The Windows 2000 operating system implements the Kerberos network authentication protocol as its default authentication method. On a Windows 2000 Domain Controller, both Kerberos and LDAP account information are managed using the Active Directory management consoles. Each Windows 2000 Domain Controller also represents a Kerberos Key Distribution Center.
Users belonging to a Windows 2000 domain are managed through the Active Directory Users and Computers management console. To access the Active Directory Users and Computers console you will need administrative privileges on the domain controller you are using as your primary KDC for Insight. You may need to provide the following information to your network administrator responsible for Active Directory Administration.
Prior to managing user accounts using Active Directory, ensure that you have defined the User Group Profiles within the Insight Administrator Tool. Refer to the Insight Administrator Tool documentation for details.
To Manage Insight User Account Information using Active Directory

  1. Log-on to the Windows 2000 Domain Controller with administrative privileges.


  1. Click Start -> Program Files -> Administrator Tools -> Active Directory Users and Computers.


  1. In the Active Directory Users and Computers, click the Users directory under the appropriate domain.

  1. Double-click on a user account you wish to grant Insight Access to.


  1. Once the Properties window appears, a series of tabs will appear along the top. The General Properties tab contains the basic information about the user.



The Telephone Number and E-mail address entries are used by Inscribe during authorization to update editorial contact information. No modifications are necessary in the General Properties tab.

  1. Click the Telephones tab to the right of General Properties. Insight requires the use of an LDAP attribute name, which stores the collection access information (e.g. Notes).


In this example, the Notes text box is used to store the Insight Access Profile information, but any unused attribute name may be configured to store this property. User accounts may be associated with a single profile, or multiple profiles by separating each profile name with a comma. See the illustration above for an example.

  1. Apply Changes to save the defined Insight Access Profile.


Restoring the Default Security Configuration for Insight


  1. In a text editor, open the InsightUserServer.dat file located in the "<insight_install>\user_manager" directory.
  2. Change the Insight Authentication Handler to the default Handler:


  1. Locate the following lines:


      1. AuthenticationHandler - the full class name of the # authentication handler to use for authentication.
        AuthenticationHandler = com.luna.insight.client.security.DefaultAuthenticationHandler
  2. Change the AuthenticationHandler property to: com.luna.insight.client. security.DefaultAuthenticationHandler. This will tell the User Manager not to use Kerberos or LDAP when authenticating users.


  1. Change the Authorization Handler to the Default Handler:
  2. Locate the following lines:


      1. AuthorizationHandler - the full class name of the # authorization handler to use for authorization.AuthorizationHandler = com.luna.insight.client.security.DefaultAuthorizationHandler
        Change the AuthorizationHandler property to: com.luna.insight.client.security.DefaultAuthorizationHandler. This will tell the User Manager not to use Kerberos or LDAP when authorizing users.

        Resources


        Windows 2000 Kerberos Interoperability, Microsoft Whitepaper
        http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx
        Kerberos interoperability issues - Paul B. Hill - MIT
        http://www.usenix.org/events/lisa-nt2000/hill/hill_html/
        Kerberos Infrastructure HOWTO
        http://cryptnet.net/fdp/admin/kerby-infra/en/kerby-infra.html
        GSS-API/Kerberos v5 Authentication
        http://java.sun.com/products/jndi/tutorial/ldap/security/gssapi.html
        Generic Security Service API Version 2: Java Bindings
        http://www.faqs.org/rfcs/rfc2853.html

        Using LDIFDE to Import and Export Directory Objects to Active Directory
        http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q237/6/77. ASP&NoWebContent=1 http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q237/6/77.ASP&NoWebContent=1


        Insight Security Release – Implementation Worksheet


        Kerberos Settings (Kerberos & LDAP Only)
        The Kerberos implementation is (select one):MIT Kerberos V5 KDC (Unix)
        Windows 2000 Domain Controller
        Realm/Domain Name_______________________
        KDC Instance_______________________
        Kerberos Principal Name for testing_______________________

        LDAP Settings (Pure LDAP / Kerberos & LDAP)
        The LDAP implementation is (select one):OpenLDAP 2.1+
        Windows 2000 Domain Controller
        Sun ONE Directory Server 5.2
        LDAP Server URL_______________________
        BaseDN_______________________
        Krb5PrincipleName Attribute Name_______________________
        Insight Profile Attribute Name_______________________
        Organization Attribute Name_______________________
        E-mail Attribute Name_______________________
        Phone Attribute Name_______________________
        User Authorization - Account Information
        Account Login Name_______________________
        Insight Profile Value_______________________


  • No labels