Solving the Extranet Authentication Riddle

Internet and web-browsers is a wonderful technology that has revolutionized how information can be accessed in a way that was unthinkable just a few years back.  Unfortunately, security solutions have not progressed in the same pace.  An example of this are Internet credit-card transactions that essentially is just a copy of the manual methods introduced some 30-40 years ago!  This white-paper addresses another problem that so far has not gotten an acceptable solution: How representatives from one organization can authenticate to partner organizations' web-servers.  The following picture shows how the majority of such systems work today:

Extranet Authentication Misery
Current Extranet authentication misery. E= Employee with browser using different user-ID/passwords at each partner site, O=Organization with server

The current solution deployed by most organizations is to let individual representatives authenticate to partner web-servers using the "classical" user-ID/password system.  This has lead to a very awkward situation where the administration of organizations' users is actually carried out by many parties with very limited convenience and security.  For the end-user it is a real nuisance to have to memorize different user-ID/password combinations for each partner site (as they are usually completely uncoordinated), and for the user's own organization this architecture introduces a lot of overhead and help-desk support when the organization changes.  For the partner organizations, the "human factor" leads to a constant risk of having incorrect user information, as there exists no scalable and secure methods for distributing neither user-ID/passwords nor getting information about new users.  A few systems like OBI, offer alternatives in the form of client-certificates that though introduce new set of problems, which lead to the inclusion of user-ID/password support in the latest OBI (3.0) specification.  A generic problem with most current extranet authentication systems is how to transfer updated additional information about users such as "profiles" for purchasers etc, which may be needed as this information is not always constant.

Introducing Purple(tm)
X-OBI have spent considerable time and resources to find a solution that combines security and convenience which we believe is a prerequisite for a new system to get market acceptance.  The result lead to the development of Purple(tm) which addresses both administrative problems by "taking back" user administration to the users' own organizations, as well as introducing state-of-the-art security but without a high price-tag and complexity.  Below is the clean structure of users and organizations that Purple(tm) supports:

Purple - Merging Security and Simplicity!
The Purple(tm) objects. E=Employee with browser, O=Organization with server & certificate

The corner-stone of the Purple(tm) concept are organization-servers equipped with organization certificates (and associated private keys), serving as the true digital equivalents to signed company papers (which has been the foundation for trust in business messages the last 200 years), rendering a single, non-forgeable, business partner electronic identity for all external "e-operations" ranging from authentications to purchase orders . The net result is a perfect blend of security and convenience!

The following shows some of the unique features of Purple(tm):

•  X-OBI's powerful Purple(tm) web-server plugin-components available in both COM and Java® flavors, enable web-developers to apply full PKI-security to critical extranet applications with the same ease as connecting databases using ADO or JDBC by encapsulating the complexities of PKI such as digital signatures and by speaking XML
• Purple(tm) dramatically reduces the need for multiple external security solutions by specifying a unified security solution between organizations, while allowing local client security solutions to develop in their own pace at each partner organization.  This is actually equivalent to the field-proven security architecture already deployed by the Internet-banks!
• For the end-user, Purple(tm) reduces authentication to a partner organization's server, to clicking on a link on the user-organization's Intranet
• Purple(tm) preserves privacy and company secrets by only requiring individuals to be fully identified by their own organization (applies primarily to B2B-systems)
• Purple(tm) supports full traceability of all external organization-to-organization actions including authentications
• Purple(tm) optionally exchanges updated customer information during authentications to mutually keep customer registers automatically in sync.
• Purple(tm) is 100% compatible with organizations' current intranet client security solutions - There is nothing new to install, distribute, or configure
• As Purple(tm) "tickets" are automatically distributed, on-demand created, XML-based certificates, tailored for each business relation, activity, and individual, as well as eliminating revocation checks by making tickets short-lived, deployment is greatly simplified for all involved parties compared to running CAs and distributing individual client-certificates for every type of business relation
• Due to the fully distributed [autonomous] administration of users and business partners, Purple(tm) is extremely cost-efficient compared to current extranet solutions.  Becoming a purchaser can often be reduced to setting a check-box in the local staff administration system!
• Being from the beginning designed with ASP-operation in mind, Purple(tm) enables efficient usage by organizations that do not have the resources or expertise required to run secure servers
Innovative but still built on industry standards
A common objection to deploying new Internet solutions is that they are not standardized.  X-OBI acknowledges this problem and has therefore based Purple(tm) on established industry standards including HTTP/HTTPS, MIME, Java, COM, HTML, PKCS #7/CMS.

Only limited by your imagination!
Although X-OBI primarily focuses on B2B-solutions, the same principles and components, apply to authentication of individuals to authorities (a hot thing in Europe), or hospitals opening-up journal files over the web to medical professionals belonging to different hospitals. The only thing that needs changes are the "tickets" that must be adapted to each situation. That usually involves creating new Purple(tm) ticket-payload XML Schemas.