| AUTHORIZATION security level |
- Common Authorization framework CommonAuthzFramework
- openOSI Authorization framework openosiAuthzFramework
- openOSI Authorization Functions openosiAuthzFunctions
- openOSI Authorization Implementation openosiAuthzImplementation
Common Authorization framework
topAuthorization
Service providers hold the authorization level. They have to address various authentication schemes depending on operating systems, applications, and internet remote access. Each of these domains has its own authorization procedures
- Operating systems
- Discretionary access control (DAC)
- Role based access control (RBAC)
- Mandatory access control (MAC)
- Multi categories access control (MCS)
- Multi level access control (MLS)
- Applications
- Access control lists
- Security groups
- XML access lists (XACML
)
- Internet remote access.
- Login mapping to organization security realm
- Login mapping to Internet dedicated security realm
- Use of HTTP REMOTE_USER variable
- Use of X.509 certificates
- Use of SAML
- Cooperation with an Identity service provider
It is out of the scope of this document to have a detailed presentation of each of these security realm, but some are ready to use X.509 certificates, others are not mature for this, or are not suitable for this. When using X.509 certificate for authorization processes the steps are usually as follows:
- Trust the Certification Authority signing certificates
- Configure services to require client certificate presentation
- Check certificate validity
- Extract whole or part of certificate's authenticated embedded information
- Certificate's DN
- Subject alternative name
- Extended key usage
- Use this excerpt directly or map it to an appropriate identifier
- Apply an authorization mechanism to this identifier
- Check certificate policy and qualified statements
- Link authorizations to accepted policy
- Produce authorizations
This is a universal and straightforward process, requiring trust in certification authorities, but it is not widely spread except for SSL/TLS encryption. Reasons rely on the underlying complexity of X.509 certificates and the lack of availability at reasonable costs of associated technologies and services. Therefore authentication with X..509 certificates was confined in governmental, corporate and sensitive areas. Breakthrough technologies and product are bringing X.509 certificates in the front:
- Availability of open source Certification Authorities (like openOSI CA)
- Identity provider services (like openOSI CA) with associated technologies (SSO and Identity federation)
- Powerful open source software for handling PKI (Public Key Infrastructure)
- Definition of Cross certification schemes allowing pervasiveness of certification authorities (Bridge CA...)
- Security requirements of Service Oriented Architecture (SOA), ESB and GRID
- Web service security standardization (WS-security) with X.509 profile
- Development of secure operating systems (SELinux) allowing secure storage of critical files (private keys)
- Development of low cost hard token able to securely store private keys (USB devices...)
- Development of environments for portable applications
openOSI Authorization framework: openOSI as Identity provider
topAuthorization
openOSI authorization level is related to its management of level of assurance and associated OID embedded in certificates signed by open OSI CA. These OID allow a service provider to make decisions about mapping its own policy to the certificate policy. openOSI publish detailed policies, therefore allowing a service provider to make assessment and mapping decisions.
In addition to the embedded policy, at INTERNET2 level of assurance, openOSI validate a subject, that is, an embedded distinguished name (DN) that may contain group definitions or elements allowing group definitions:
- OU (Organization unit) element
- O (Organization) element
- UID (User ID) always contain a validated e-mail address which domain part could be used
At INTERNET2 level of assurance, openOSI may also validate a subject alternative name embedded in the certificate that may contain elements allowing group definitions or authorization decision:
- RFC822 Name (always), that is, e-mail domain part
- DNS name
- IP address (RDNS was correctly set)
- URI
- UPN (should be reachable on Internet)
- GUID (Globally Unique Identifier)
 | Useful Information
It is deprecated to put the FQDN name (fully qualified name) in common name (CN) element for host SSL/TLS identification, it should be in the subject alternative name, inside DNS name element. Note that all systems are not up to date. openOSI puts the FQDN in both places. Also note that it is deprecated to put e-mail address in certificate subject, it should be in subject alternative name. openOSI puts the e-mail address in the subject UID value and in the subject alternative name. |
openOSI Authorization functions
topAuthorization
openOSI helps authorization process with the following resources:
openOSI Authorization implementation
topAuthorization
| openOSI relies on the following Certifications authorities |
|
- openosiCA3-EU
- CN=openosiCA3-EU
- OU=PKI
- O=openosi
- C=EU
|
|
openOSI Level of assurance
|
|
|
- openosiCA3-DC
- CN=openosiCA3-DC
- OU=PKI
- DC=openosi
- DC=org
|
|
|
|
