Browse Prior Art Database

A customizable mechanism for generating an X.500 Distinguished Name, when a client has not presented an X.509 certificate.

IP.com Disclosure Number: IPCOM000013349D
Original Publication Date: 2001-Aug-17
Included in the Prior Art Database: 2003-Jun-18
Document File: 1 page(s) / 43K

Publishing Venue

IBM

Abstract

A procedure is disclosed for generating a customized a Distinguished Name(DN) for a client of an EJB who has not presented an X.509 client certificate. When implementing the getname() method of the java.security.Principal interface, the CORBA to EJB mapping rules suggest that the generated name must be the client's (DN) if the client is authenticated over the Secure Sockets Layer with an X.509 client certificate. The mapping rules do not prescribe what the generated name should be if the client has not presented an X.509 certificate (because the SSL client authentication protocol was not used, or because the client did not provide a certificate even when the SSL protocol requested one) but it is desirable for consistency that it should be a DN in the other cases as well. Proposed is a method of generating a name, to ensure a consistent format for getname() method output independently of whether a certificate is presented, by providing a customizable way of generating an X.500 user-defined DN. The implementation of Principal.getName() checks whether a client certificate was provided, and if it was, extracts the client's DN from it, using the rules of RFC1779 and RFC2253 to generate a textual representation of the binary BER-encoded DN contained in the certificate. If a client certificate is absent, the implementation gathers sufficient information to build a DN from other sources: most of the DN information is obtained from an X.509 certificate being used to identify the server system , enhanced by information unique to the current user executing the Principal.getName() method. All this information is passed to a customizable user exit program, which uses the information to build a new DN in a format described by RFC1779 and RFC2253. Title, email_address, organizational_unit, organization, locality, state_or_province, and country are obtained from the server certificate and passed to the user exit as "installation-wide" data, while the userid and username of the current user are obtained from the local security manager and passed to the user exit as "user-specific" data. This user-specific data can then be used to generate the common_name section of the DN, or potentially generate an e-mail address to override the one obtained from the server certificate. This ensures that the name returned by the Principal.getName() method has a consistent format whether the client has a certificate or not, allows the installation to customize the value returned by Principal.getname() by coding the user exit, and allows the installation to provide configurable input to the user exit by configuring the contents of the server certificate. This allows installation-wide content of the DN (such as Country and Organization) to be configured easily without additional programming in the user exit, and allows the installation to provide user-specific content of the DN (such as Common-name or E-mail address) derived from the user-unique data passed to the user exit. 1

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 1

  A customizable mechanism for generating an X.500 Distinguished Name, when a client has not presented an X.509 certificate.

A procedure is disclosed for generating a customized a Distinguished Name(DN) for a client of an EJB who has not presented an X.509 client certificate. When implementing the getname() method of the java.security.Principal interface, the CORBA to EJB mapping rules suggest that the generated name must be the client's (DN) if the client is authenticated over the Secure Sockets Layer with an
X.509 client certificate. The mapping rules do not prescribe what the generated name

should be if the client has not presented an X.509 certificate (because the SSL client authentication protocol was not used, or because the client did not provide a certificate even when the SSL protocol requested one) but it is desirable for consistency that it should be a DN in the other cases as well. Proposed is a method of generating a name, to ensure a consistent format for getname() method output independently of whether a certificate is presented, by providing a customizable way of generating an X.500 user-defined DN. The implementation of Principal.getName() checks whether a client certificate was provided, and if it was, extracts the client's DN from it, using the rules of RFC1779 and RFC2253 to generate a textual representation of the binary BER-encoded DN contained in the certificate. If a client certificate is absent, the implementation gathers sufficient information to build a DN from other sources: most of the DN information is obtained from an X.509 certifi...