Single Sign-On

Administrators frequently spend a lot of time managing user names and passwords creation, suspension, privilege modification, and account deletion authorization, authentication and provisioning. The employee logs on using various passwords to access enterprise assets and resources which was previously time consuming and expensive for administrators to manage. Managing identities becomes more complex as the number of users, applications and systems grows, it is not only for employees who have to remember the right IDs and passwords to use each of their applications but also for administrators who have to track and manage it all.

Single sign-on is a simple and effective way to access data from multiple sources .

PKI

Public Key Infrastructures does not require secret IDs and passwords to be previously known by the authenticating party. A principal advantage for PKI based security is the ability to support single sign-on by using public key certificates. With a PKI-secured message, an online service is not necessary for any two parties to communicate securely. In addition, the ability to have a hierarchical key structure, and real-time analysis of the path through the hierarchy, makes it possible for parties to securely communicate without prior business arrangement. PKI requires both authentication and authorization to take place for remote access control. It needs not only to know who a remote user is, but also to know what the user is permitted to do. Although PKI provide comprehensive support for authentication, PKI require the use of digital certificates for managing authentication.

OCSP is a real time mechanism for certificate revocation and certificate validation checking within a PKI deployment.

OCSP

Online Certificate Status Protocol is a online request-response pair PKI information access protocol composed of standardized request and response types for certificate revocation and validation status. When a remote user attempts to access a server, OCSP sends a request for certificate status information. The server sends back a response of "current", "expired," or "unknown." An OCSP request message is composed of protocol version number, a request type object identifier and other request data relevant to a particular request type. Initially the OCSP responder certificate is located and the signature on the OCSP request checked using the responder certificate's public key. Then a normal certificate verify is performed on the OCSP responder certificate building up a certificate chain in the process.

Although OCSP enables applications to determine the revocation state of an identified certificate , OCSP can not check that certificates are signed correctly . Although a set of trusted public keys from which certificate chains may be constructed , OCSP can not check that the certificate chains to an acceptable trust point . Although a set of intermediate certificate authorities from which the trust chain may be constructed , OCSP can not check that each certificate in the chain contains an acceptable certificate policy identifier to ensure that certificates are not being misused. OCSP by itself is not sufficient to meet our customer's full requirements .

OCSP requires that every user and every application verify the identity of everyone they communicate with and ensure that the counter-party identity is appropriate for the transaction and that the identity is still valid (not been revoked). OCSP deployment is too cumbersome and costly for the technology to achieve widespread use.

BOXML creates a trust service that shields clients from complexity by providing an XML interface to PKI and using Dynamic XML Encryption ,Multiple XML Signature and Time-Stamp Universal Unique XML Identification .

BOXML

Traditionally, with PKI all trust decisions are offloaded to the cryptographic client. The certificate verifier needed to support all the complex functionality such as certificate path building, certificate path verification and certificate status checking. This requires complicated programming libraries and configuration information. It is important to minimize client code and configuration complexity for PKI.Furthermore, such applications were heavy in terms of PKI code making them difficult to be deployed on thin memory devices e.g. PDAs and cell phones .

BOXML trust server supports XKMS( XML Key Management Specification) by Dynamic XML Encryption ,Multiple XML Signature and Time-Stamp Universal Unique XML Identification. XKMS replaces many PKI protocols, such as OCSP(Online Certificate Status Protocol),LDAP( Lightweight Directory Access Protocol),CRL(Certificate Revocation Lists),CMP(Certificate Management Protocol ) and SCEP (Simple Certificate Enrollment Protocol ), with XML-based protocols such as Register Service, Revoke Service, Recover Service, Locate Service and Validate Service . With XKMS, trust functions reside in BOXML accessible via easily programmed XML transactions so they can be centralized and applied consistently across platforms. The only configuration information an BOXML’s client needs is the URL of the BOXML , and the certificate which BOXML will use to sign its response. Developers can allow applications to delegate all or part of the processing of XML multiple digital signatures and XML partial encrypted elements to BOXML . Different trust models can be supported by using different URLs. Anything to do with PKI can be delegated to BOXML trust server.

home