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

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...