| AUTHENTICATION security level |
- Common framework CommonAuthFramework
- openOSI Authentication framework openosiAuthFramework
- openOSI Authentication Functions openosiAuthFunctions
- 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:
- Username i.e: (WS-security Username token profile)
- Remote Authentication Dial-In User Service (RADIUS) RFC2867, RFC2868 and RFC3575
- PAP, CHAP
- EAP series (including X.509 aware mechanism like EAP-TLS, see hereafter)
- DIAMETER RFC3588, RFC4004, RFC4005, RFC4072, RFC4740,
- IPSEC (may relying on X.509 certificates)
- TLS (relying on X.509 certificates)
- IEEE 802.1 with Extensible Authentication protocol (EAP) RFC3748 and RFC4017
- EAP-TLS RFC2716 (relying on X.509 certificates)
- others 40 EAP realms (LEAP, EAP-MD5, EAP-TTLS, EAP-IKEv2 ....)
- Kerberos i.e: (WS-security Kerberos token profile)
- X.509 certificates i.e: (WS-security X509 token profile)
- SAML (WS-security SAML token profile)
- Leaving the choice of security mechanism to implementers and deployers
- But recommend, and in some cases mandate, a variety of security mechanisms
- SSL 3.0 and TLS 1.0 for transport-level security (relying on X.509 certificates)
- XML encryption and XML signature (MAY rely on X.509 certificates)
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
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
|
|
- client auth
- emailProtection
- MS Smartcard Logon
|
|
|
|
- serverAuth
- ipsecEndSystem
- ipsecTunnel
- ipsecUser
- timeStamping
- ocspSigning
|
|
| Certificate policy associated with category and level of assurance |
|
|
openOSI Level of assurance
- INTERNET2 (for openOSI & cooperation)
- INTERMEDIATE (for openOSI & cooperation)
- HIGH (for openOSI)
|
|
|
|
- BASIC
- INTERNET2
- INTERMEDIATE (for openOSI roles)
|
|
|
|
|
- [oid:1.3.6.1.4.1.27630.1.2.3]
|
|
|
- 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]
|
|
|
- INTERNET2
- INTERMEDIATE (for openOSI)
|
- [oid:1.3.6.1.4.1.27630.1.2.5]
- [oid:1.3.6.1.4.1.27630.1.3.5]
|
|
|
- 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]
|
|
|
|
- [oid:1.3.6.1.4.1.27630.1.2.7]
|
