Dashboard > Identification and Authentication credentials > Home > Authentication
  Identification and Authentication credentials Log In   View a printable version of the current page.  
  Authentication
Added by Jose REMY, last edited by Jose REMY on Aug 01, 2007
Labels: 
(None)

AUTHENTICATION security level


  1. Common framework CommonAuthFramework
  2. openOSI Authentication framework openosiAuthFramework
  3. openOSI Authentication Functions openosiAuthFunctions
  4. openOSI Authentication Implementation openosiAuthImplementation


Common Authentication framework

topAuthentication

It is a recognized approach to allow security integration with the major well known authentication standards. Service oriented Architecture (SOA) and new trends for Enterprise Application Integration (EAI) define a technological approach resulting notably in Web Services specifications. We draw the following excerpt related to authentication from the Web Service security specification :

This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. The token formats and semantics for using these are defined in the associated profile documents

This is a common approach of quite all new standards related to network security. An entity may choose its preferred security realm mainly among followings:

For SSO, CAS (Central Authentication Service) is a kind of Kerberos-like for the Web, supporting several security realms including X.509.

openOSI Authentication framework

topAuthentication

openOSI uses X.509 certificates as its preferred security realm. I believe X.509 certificates may bring Single Sign On solutions (SSO) as well as a coherent answer to a variety of security needs. Unifying top level security policies in the frame of a PKI (Public Key Infrastructure) allows focussing management of security on distributed PKI resources and associated configurations. It allows concentrating provisions in a single security realm when fighting against heterogeneous threats. It also allows for loosely coupling between different security levels (Identification, Authentication, Authorization); that is, it ease collaboration between identity service providers and service providers handling the Authorization level. The link between openOSI Authentication level and external Authorization level is the Identification level; that is, public availability of identities with associated public certificates, certificates revocation lists, and various certificates' status mechanisms like OCSP.

Directory and Certificate DN mapping

To enhance openOSI authentication integration, there is a mapping between openOSI directory's DN (Distinguished Name) resulting from the Directory Information Tree (DIT), and certificate's DN embedded as certificate subject when openOSI signs certificates' requests.

Once an entity is identified, it can be authenticated, and then authenticated identity attributes may be added to the core identity. These attributes may help for Authorization, but directories' security is not strong enough to allow relying entirely on identity attributes for Authorization processes. The +trust should focus on the content of certificate subject (DN), certificate extensions, and qualified statements, + taking into account the level of assurance oid:1.3.6.1.4.1.27630.1.0.1.4.


openOSI Authentication functions

topAuthentication

SUMMARY



openOSI Authentication implementation

topAuthentication


openOSI certificate's subject DN

It has the following form (UTF-8 format):

  • DC style except root CA which are in classical style (dc=openosi,dc=org)
  • CN (Common name) unique in openOSI scope
    • any combination of Firstname Lastname (Firstname.Lastname ...)
    • any combination of Firstname Middlename Lastname (FirstnameM.Lastname ...)
    • any previous combination with a suffix number (i.e: 4 last digit of social security number)
    • country code plus any national ID (i.e: US-social security number)
    • anything unique in openOSI scope
  • UID (User ID) Globally unique, that is an e-mail address
  • OU (Organization unit) category
    • People: an identified single human
    • VirtualPeople: a nickname, pseudo or robot behaving like a human
    • Hosts: servers and devices
    • VirtualHosts: virtual servers, hosts and devices
    • Services: software agents, daemons and services
    • Code: piece of software code

Example

DN:cn=Firstname.Lastname,uid=emailAddress,ou=VirtualPeople,dc=openosi,dc=org

Additional DN components may exist depending on the corresponding authentication level of assurance.

Useful Information

In the frame of openOSI Single Sign On, there is no need for additional components because only class 1 (Basic) and class 2 (Internet2) certificates are normally provided. That is, only this core DN is embedded in certificate subject.


openOSI standard groups in certificate DN (INTERNET2 level of assurance)

They have the following form:

  • OU=groups
  • OU=organization unit or
  • O=organization
  • DN:cn=FirstnameLastname,uid=emailAddress,ou=organisationalUnit,ou=groups,ou=category,dc=openosi,dc=org or
  • DN:cn=FirstnameLastname,uid=emailAddress,o=organisation,ou=groups,ou=category,dc=openosi,dc=org

In openOSI framework this latest group definition is used when it is necessary to identify a cooperating entity or internal organization unit, that is with INTERMEDIATE or HIGH authentication level of assurance (class 3 & 4) which are not widely available (class 3 needs peer to peer agreement). O (organization) or OU (organizationUnit) components help Authorization processes using groups.

Extended key usage associated with category

topAuthentication

openOSI Category


  • People
  • VirtualPeople
Extended key usage


  • client auth
  • emailProtection
  • MS Smartcard Logon
OID


  • Hosts
  • VirtualHosts
  • serverAuth
  • Services
  • serverAuth
  • ipsecEndSystem
  • ipsecTunnel
  • ipsecUser
  • timeStamping
  • ocspSigning
  • Code
  • codeSigning


Certificate policy associated with category and level of assurance

openOSI Category


  • People
openOSI Level of assurance


  • INTERNET2 (for openOSI & cooperation)
  • INTERMEDIATE (for openOSI & cooperation)
  • HIGH (for openOSI)
openOSI Policy OID



  • VirtualPeople


  • BASIC
  • INTERNET2
  • INTERMEDIATE (for openOSI roles)



  • Hosts


  • INTERNET2


  • [oid:1.3.6.1.4.1.27630.1.2.3]


  • VirtualHosts


  • INTERNET2
  • INTERMEDIATE (for openOSI)


  • [oid:1.3.6.1.4.1.27630.1.2.4]
  • [oid:1.3.6.1.4.1.27630.1.3.4]


  • Services


  • INTERNET2
  • INTERMEDIATE (for openOSI)



  • Code


  • INTERNET2
  • INTERMEDIATE (for openOSI)


  • [oid:1.3.6.1.4.1.27630.1.2.6]
  • [oid:1.3.6.1.4.1.27630.1.3.6]


  • DRM (licenses)


  • INTERNET2


  • [oid:1.3.6.1.4.1.27630.1.2.7]

Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.4.2 Build:#703 Mar 12, 2007) - Bug/feature request - Contact Administrators