| IDENTIFICATION security level |
- Common Identification framework CommonIdFramework
- openOSI Identification framework openosiIdFramework
- openOSI Identification Functions openosiIdFunctions
- openOSI Identification Implementation openosiIdImplementation
- openOSI Directory Information Tree openosiDIT
- openOSI Object Classes openosiObjectClasses
Common framework
topIdentification
There are widely accepted standards, techniques, and tools to manage identification, for example LDAP directories. There is a very common risky approach over the Internet, tending to use directories for Authentication, especially when passwords are stored. By nature these directories are oriented toward wide public access (phone books). They answer the need of "Information discovery" and description. This appears when a UDDI schema is added to LDAP for "Universal Description, Discovery and Integration". LDAP directories are very flexible and many identification attributes can be used.
Many other repositories are used for identity, including national registry with birth name, social security numbers, driver license numbers.... The challenge of identity is to be unique in the scope where it is used.
In real life entity identification may have several formal attributes.
| Attribute |
Signification |
Comment |
| UID |
User ID |
Different structure for Microsoft and UNIX |
| RUID |
Real UID |
UNIX (remain unchanged) and MS office |
| EUID |
Effective UID |
UNIX (may temporarily change for other ID) and MS office |
| GID |
Group ID |
UNIX |
| UUID |
Universally Unique Identifier |
OSF standard for DCE |
| GUID |
Globally Unique Identifier (UUID) |
Used by Microsoft |
| UPN |
User Principal Name |
Used by Microsoft (e-mail address) |
| SID |
Security Identifier |
Used by Microsoft for every account (depends on domain) |
| Principal |
Kerberos user ID |
Microsoft and UNIX Kerberos |
| DN |
Distinguished Name |
Microsoft and UNIX LDAP |
| RDN |
Relative Distinguished Name |
Microsoft and UNIX LDAP |
| CN |
Common Name |
Microsoft and UNIX LDAP |
| authcID |
authentication ID |
UNIX SASL library |
| authzID |
authorization ID |
UNIX SASL library |
| REMOTE_USER |
HTTP environment variable |
web environments |
| username |
WS-security username token (3 forms) |
web service (WS) environments |
| SAML assertion |
Security Assertion Markup Language authentication token |
web service (WS) environments |
A coherent framework including all of these identifiers builds ground for Single Sign On (SSO). The challenge of SSO is to provide uniqueness for managed entities
openOSI framework
topIdentification
openOSI uses DN Distinguished Name space, with LDAP directories to help confirming a claimed identity. No sensitive information is embedded in directories, but groups' identification. To protect privacy, although anonymous access is granted, a maximum of one answer is returned for each query; that is, normal use is not to browse lists, but to get confirmation of a known identity. Directories used for identification are part of a security process; they are not the same as directories used for example for discovery. The underlying assumption is that Identity provider business processes' are distinct from Universal Description and Discovery business processes closest to marketing activities. The link between openOSI Identification level and openOSI Authentication level is the entity X.509 public certificate.
Note that a certificate includes a DN in its subject, and that a DN may include an UID value, as many other values described in openosiObjectClasses. The openOSI authentication level holds DN definition for certificates.
 | Public information for Authentication
openOSI takes advantage of X.509 authentication scheme relying on a public key and an associated private key. The public key is published in a public repository with anonymous access: openOSI LDAP directory to ensure identification processes. The private key is not hold by openOSI but by the user or client entity. openOSI ensure signature of certificate signing request and revocation processes with a given level of assurance (see oid:1.3.6.1.4.1.27630.1.0). |
openOSI Identification functions
topIdentification
- Analysis of authentication request
- Formal analysis (syntax)
- Identifier recognition (semantic)
- Identifier content (arbitrary content)
- Check for pre existing identification attributes
- openOSI identifiers scope
- Known global identifier (e-mail address)
- Known third part identifiers
- Definition of Entity claiming authentication
- Identity category
- Human
- Virtual human
- Server (host)
- Virtual host
- Service (daemon)
- Code (software)
- Implicit level of assurance
- Scope of submitted information
- Type and quality of submitted information
- Limitations screening
- Lawfull purpose
- Counter terrorism and organized crime
- openOSI and accepted third parts black lists
- Completeness
- Accepted identity subject to authentication
- Candidate level of assurance
- Authentication request transformation
openOSI implementation
topIdentification
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 virtual hosts
- Services: software agents, daemons and services
- Code: piece of software code
Example
DN:cn=FirstnameLastname,uid=emailAddress,ou=VirtualPeople,dc=openosi,dc=org
Additional DN components may exist depending on the corresponding authentication level of assurance. That is these additional components are considered as "Identity properties" granted later, after Identity Authentication.
 | 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 the core DN is authenticated. |
They have the following form:
- OU=groups
- DN:cn=group.emailAddress,ou=groups,ou=category,dc=openosi,dc=org
The CN value is concatenation of "group" (dot) emailAddress the resulting value group.emailAddress is supposed to be a Globally unique personal group; that is a group attached to a identity. It allows for highly sensitive replacements as proxy identities definition. When an identity is strongly defined it appears that its possible discontinuity should be managed (Revocation, death, temporary unavailability...).
or this one
- OU=groups
- OU=organization unit or O=organization
- DN:ou=organisationalUnit,ou=groups,ou=category,dc=openosi,dc=org or
- DN: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).
topIdentification
The DIT comes from the core openOSI DN:
- dc=org
- dc=openOSI
- ou=<category>
- ou=<category>
....
- ou=<category>
- cn=Firstname.Lastname
- cn=Firstname.Lastname
....
- cn=otherFirstname.otherLastname
- uid=emailAddress
- uid=emailAddress
...
- ou=groups
****cn=group.emailAddress
****cn=group.emailAddress
....
****ou=OrganizationUnit
****ou=OrganizationUnit
....
****o=Organization
****o=Organization
...
| Virtual Identities
It is possible to have multiple UID for a given CN, that is an easy way to manage several Virtual identities linked to one real or virtual identity. |
openOSI object classes
topIdentification
LDAP directories are very flexible, depending on the different supported schemas. openOSI uses only default openLDAP schemas for its security processes. The link to the authentication level is the userCertificate attribute or the strongAuthenticationUser object class allowing userCertificate attribute for non human entities.
| Objectclasses for People or VirtualPeople |
objectClass: top
objectClass: person (see core schema RFC4519
)
objectClass: organizationalPerson (see cosine schema RFC4524)
objectClass: inetOrgPerson (see inetorgperson schema RFC2798)
| Objectclasses for Hosts or VirtualHosts |
objectClass: top
objectClass: device (see core schema RFC4519)
objectClass: strongAuthenticationUser (see core schema RFC4519)
| Objectclasses for Services |
objectClass: top
objectClass: applicationProcess (see core schema RFC4519)
objectClass: strongAuthenticationUser (see core schema RFC4519)
objectClass: top
objectClass: document (see cosine schema RFC4524)
objectClass: documentSeries (see cosine schema RFC4524)
objectClass: strongAuthenticationUser (see core schema RFC4519)
