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

IDENTIFICATION security level


  1. Common Identification framework CommonIdFramework
  2. openOSI Identification framework openosiIdFramework
  3. openOSI Identification Functions openosiIdFunctions
  4. openOSI Identification Implementation openosiIdImplementation
  5. openOSI Directory Information Tree openosiDIT
  6. 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


openOSI core 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 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.


openOSI standard groups

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).

openOSI Directory Information Tree (DIT)

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)

Objectclasses for Code

objectClass: top
objectClass: document (see cosine schema RFC4524)
objectClass: documentSeries (see cosine schema RFC4524)
objectClass: strongAuthenticationUser (see core schema RFC4519)

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