U.S. Department of Agriculture, National Finance Center (NFC), 13800 Old Gentilly Rd., Bldg 350, MAF, New Orleans, LA 70129

70 -- SOURCES SOUGHT FOR SINGLE-SIGNON AND SECURITY ADMINISTRATION PRODUCT SOL NFC-00-RFI-009 DUE 031000 POC Mrs. Freddie D. Moses, Contracting Officer, 504-255-5911 E-MAIL: USDA, National Finance Center, freddie.moses@usda.gov. This is a Sources Sought Synopsis. USDA, OFCO, National Finance Center (NFC), is seeking information on a trusted single-signon and security administration product. The following is a list of the functional requirements of the product, as set forth by the USDA National Finance Center. The requirements are broken down in four major categories: The USDA National Finance Center is seeking information on a trusted single-signon and security administration product. The following is a list of the functional requirements of the product, as set forth by the USDA National Finance Center. The requirements are broken down in four major categories: Security Administration Management, Identification and Authorization, Access Control, and Data Integrity/Confidentiality/Encryption. Under each category the requirements are listed in the most critical to least critical order. Assumptions 1. All USERIDs are unique, no two USERIDs can be the same. This prevents two or more users from having the same USERID. 2. The vendor should provide the requisite software to provide functionality on all supported platforms. 3. The term multiple platforms refers to both hardware and software. Software: Windows 95/98/NT, UNIX, MVS OS390, Novell, GroupWise, etc. Hardware: Mainframe, Novell/NT/Proxy/FTP Servers, RS6000, etc. Security Administration Management Single Point of Administration All administration of the product should be done from a single point. This enables an administrator to provide support for multiple platforms from one single platform device. This also enables the user to only have to change his/her password on one platform and have it propagate across all other platforms. Administration for Multiple Platforms The product should provide for the administration of the product from any of the supported platforms. This enables the administrator to support the product from any platform of his/her choice. Ability to Enforce Enterprise/Global Security Rules The product should provide the ability to enforce security rules over the entire enterprise regardless of platform. This will ensure consistent security over resources on all protected platforms. Audit Trail All changes, modifications, additions, and deletions should be logged. This ensures that all security changes are recorded for review at a later time. Security Administration Management (continued) Real-Time and Batch Update All changes should be made on-line/real-time. The ability to batch changes together is also important to enable easy loading or changing of large numbers of security resources or users. Synchronization Across All Entities The product should synchronize security data across all entities and all platforms. This ensures that all security decisions are made with up-to-date security information. Ability to Trace Access The product should enable the administrator to be able to trace access to systems regardless of system or platform. Scoping and Decentralization of Control The product should be able to support the creation of spans of control so thatadministrators can be excluded from or included in certain security control areas within the overall security setup. This enables an administrator to decentralize the administration of security functions based on the groups/nodes/domains/enterprises that the decentralized administrator has control over. Ability To Group Users The product should enable the grouping of like users where applicable. These groups should be handled the same way individual users are handled. This will enable more efficient administration of access authority. Ability to Recreate Information logged by the system should be able to be used to "backout" changes to the security system. This enables mass changes to be "backed out" of production. One Single Product The product should be a single product, not a compendium of several associated products. Modularity for the sake of platform-to-platform compatibility is acceptable and favored. Usage Indicators The product should include usage data on each user. Usage data should include usage count for each application/domain, last date used, last date modified, date created, etc. Physical Terminal/Node/Address Control The product should have the ability to restrict or control access on the basis of a terminal, node, or network address. This ability will enable administrators to provide access control by physical location. Security Administration Management (continued) Release Independent/Backward Compatible All releases of the product should be backward compatible or release independent. Features of new releases should co-exist with current features and not require a total reinstallation of the product. Implementation in Phases The product should support a phased implementation to enable administrators to implement the product on individual platforms without impacting other platforms. This will enable installation on a platform-by-platform basis if desired. Ability to Interface with Application/Database/Network Security The product should be able to interface with existing application, database, or network security by way of standard security interfaces. This will ensure that the product will mesh with existing security products installed. Ability to Interface with Session Manager The product should be able to interface with existing session manager software, in particular, CL-Super Session. Software Release Distribution New releases of the product should be distributed via the network from a single distribution server of the administrator's choice. This enables an administrator to upgrade the product on any platform without physically moving from platform to platform. Flexible Cost The cost of the product should be reasonable. Several cost scenarios should be considered such as per seat, CPU, site licensing and MIPS pricing. Pricing should include disaster recovery scenarios. Ability to Create Security Extract Files The product should have a feature to produce an extract file of the security structure and logged data. This enables the administrator to write his/her own reporting systems via SAS or any other language. Test Functionality The product should include a test facility to enable administrators to test security changes before placing them into production. Ability to Tag Enterprise/Domain/Node/Application. The product should be able to add a notation or "tag" specifying Enterprise/ Domain/ Node/ Application in order to provide the administrator with a way to identify the entity. This enables the administrator to denote the tagged entity and possibly perform extra or non-standard operations on the entity based on that tag. Security Administration Management (continued) User Defined Fields The product should have a number of user customizable/user-defined fields. This enables a user to provide for informational needs that are specific to his/her organization. Target Platform Flexibility Administrator should be able to have the option of directing security command to a particular platform or to multiple platforms. Identification and Authorization Support RACF Pass Ticket Technology The product should support IBM's RACF Pass Ticket technology ensuring that the product can reside in an environment using Pass Ticket technology to provide security identification and authorization. Support Password Rules All common password rules should be supported: Use or non-use of passwords Password length rules Password aging rules Password change intervals Password syntax rules Password expiration warning message Disallow previous x passwords Password uniqueness rules Limited number of logons after a password expires Customer defined rules Logging of All Activity All activity should be logged, or able to be logged, for all activities. The logging should include the origin of the logged item or action, the destination, the application involved, and the platform involved. This enables the administrator to provide a concise map of all activity on the enterprise. The degree of logging should be controlled by the administrator. Single Revoke/Resume for All Platforms The product should support asingle revoke or resume of a USERID regardless of the platform. This ensures that a user can be revoked or resumed with only one command from one source or platform. Support a Standard Primary USERID Format All common USERID syntax rules should be defined by the administrator and supported across all platforms. Identification and Authorization (continued) Auto Revoke After X Attempts Users should be revoked from system access after a specified number of invalid attempts. This threshold should set by the administrator. This ensures that invalid users are prevented from retrying signons indefinitely. Authorization Server On Mainframe Platform The product should provide for the authentication server to reside on a OS390 Mainframe platform. Single Point of Authorization All authorizations should be made at a single point, i.e., an authentication server. The product should not need to go to several versions of the product on several platforms to gain the needed access to a resource. This provides not only asingle point of administration for the product, but also reduced network security traffic. Support User Exits/Options The product should support the addition of user exits/options that could be attached to the base product at strategically identified points of operation. The points would include: signon, signoff, resource access check, etc. This enables an administrator or key technical support personnel to add exit/option code to the package to provide for specific security needs above and beyond the scope of the package. Insure USERID Uniqueness The product should ensure that all USERIDs are unique, no two USERIDs can be the same. This prevents two users from having the same USERID. Support Signons from Multiple Devices The product should support signons from a variety of sources. LAN/WAN, workstations, Laptops/Notebooks, Dial-in, dumb terminals, etc. This ensures that all signon sources are able to provide signon access. Customizable Messages The product should support the use of customized security messages. This will enable an administrator to customize messages to fit the needs of the enterprise. Access Control Ability to Support Scripting -- Session Manager Menus The product should support the use of session managers, i.e. CL Super Session, and session manager scripting. This enables the use of a session manager script in those sites and instances where they are needed or required. Access Control (continued) Privileges at Group/System Level The product should support administration privileges at a group level (Based on span of control) or on the system level. This enables the product to be administered by several administrators without the administrators authority overlapping. Default Protection Option The product should provide for the option of protecting of all resources and entities as the default. The product should also have the option of having the default as being unprotected. Support Masking/Generics The product should support security profiles containing generic characters that enablethe product to make security decisions based on groups of resources as opposed to individual security profiles. This enables the administrator to provide security profiles over many like-named resources with the minimum amount of administration. Data Integrity/Confidentiality/Encryption No Clear Text Passwords (Net or DB) At no time should any password be available on the network or the security database in clear, human-readable form. The only exception is the use of dumb terminals where the terminal does not support encryption techniques. This will ensure the integrity of the users' passwords in all cases with the exception of dumb terminals. Option to Have One or Distributed Security Databases The product should support the option of having a single security database or several distributed security databases on different platforms. This enables an administrator to use a distributed database on a platform that may be sensitive to increased activity rather than a single security database. The administrator will control who can and if they can update distributed databases. Inactive User Time-out All users who are inactive for a set period of time during a session should be timed out and signed off of all sessions. This ensures that a user who becomes inactive for whatever reason does not compromise the security of the system by providing an open terminal to a system. This feature should be controlled by the administrator and have two layers: 1. At the session manager/screen level. 2. At the application/platform level. Inactive User Revoke All users who have not signed on within a set period of time should be revoked. This period should be configurable by the administrator. This will ensure that USERIDs are not valid if not used within a set period of time. Data Integrity/Confidentiality/Encryption (continued) Ability to Backup Security Database to Choice of Platforms/Media The product should be able to backup its security database to a choice of supported platforms or storage media. This enables the administrator to have a variety of destinations available for the security database backup. Encryption Should Be Commercial Standard (Presently DES) The encryption used in the product should be standard. That standard is presently DES which is 128 bit encryption but could change as new encryption standards are made. This will ensure that the product will be based on a tested, generally accepted encryption base. Integrity of Security Database The database used by the product to store security information and parameters should be protected from changes via any source other than the product itself. Generic file edit tools should not be able to view or update the security database. Optional Application Data Encryption The product should provide the optional ability to interface to encrypted application data if the encryption techniques are provided. This enables the product to interact with existing application encrypted data. Failsoft Ability The product should have the ability to perform at a degraded degree without access to the security database. This ability should rely on administrator input on an as needed basis to enable a user to signon, access resources and signoff. This enables the product to at least work in a degraded mode in an emergency in such a fashion that security is not compromised. This is not a request for proposal, and in no way obligates the government in an award of any contract. The government does not intend to compensate any sources for any information provided. Interested sources are invited to respond to this Sources Sought Announcement by providing in writing, at a minimum, the following: a) Company Brochure indicating area of expertise, company size and locations of facilities, b) any information which might indicate that the offerer has the technical expertise and applicable background to provide the required system, and c) Demonstration of the offerer's ability to provide technical support for the item described above. Proprietary information should be properly identified. All respondents shall indicate whether they ar a small, minority or handicapped owned business. Interested sources may submit responses any time after the release of this Sources Sought synopsis, but not later than March 10, 2000. Posted 02/14/00 (W-SN425182). (0045)

Loren Data Corp. http://www.ld.com (SYN# 0243 20000216\70-0002.SOL)