banner1banner2banner3
123

Red Hat Single Sign On (SSO)

Advantages of Red Hat Enterprise Linux Single Sign-on:
Numerous security mechanisms currently exist that utilize a large number of protocols and credential stores. Examples include SSL, SSH, IPsec, and Kerberos. Red Hat Enterprise Linux SSO aims to unify these schemes to support the requirements listed above. This does not mean replacing Kerberos with X.509v3 certificates, but rather uniting them to reduce the burden on both system users and the administrators who manage them.
To achieve this goal, Red Hat Enterprise Linux:
  • Provides a single, shared instance of the NSS crypto libraries on each operating system.
  • Ships the Certificate System's Enterprise Security Client (ESC) with the base operating system. The ESC application monitors smart card insertion events. If it detects that the user has inserted a smart card that was designed to be used with the Red Hat Enterprise Linux Certificate System server product, it displays a user interface instructing the user how to enroll that smart card.
  • Unifies Kerberos and NSS so that users who log in to the operating system using a smart card also obtain a Kerberos credential (which allows them to log in to file servers, etc.)
Overview of the Enterprise Security Client
The Enterprise Security Client is a tool for Red Hat Certificate System which simplifies managing smart cards. End users can use security tokens (smart cards) to store user certificates used for applications such as single sign-on access and client authentication. End users are issued the tokens containing certificates and keys required for signing, encryption, and other cryptographic functions.


About Smart Card Management
Certificate System creates, manages, renews, and revokes certificates, as well as archiving and recovering keys. For organizations which use smart cards, the Certificate System has a token management system — a collection of subsystems with established relationships — to generate keys and requests and receive certificates to be used for smart cards. These relationships are show in Figure 1.1, “How Certificate System Manages Smart Cards”.
Four Certificate System subsystems are involved with managing tokens:
  • The Token Processing System (TPS) interacts with smart cards to help them generate and store keys and certificates for a specific entity, such as a user or device. Smart card operations go through the TPS and are forwarded to the appropriate subsystem for action, such as the Certificate Authority to generate certificates or the Data Recovery Manager to archive and recover keys.
  • The Token Key Service (TKS) generates, or derives, symmetric keys used for communication between the TPS and smart card. Each set of keys generated by the TKS is unique because they are based on the card's unique ID. The keys are formatted on the smart card and stored on the TPS and are used to encrypt communications, or provide authentication, between the smart card and TPS.
  • The Certificate Authority (CA) creates and revokes user certificates stored on the smart card.
  • Optionally, the Data Recovery Manager (DRM) archives and recovers keys for the smart card.
The Enterprise Security Client is the conduit through which TPS communicates with each token over a secure HTTP channel (HTTPS), and, through the TPS, with the Certificate System.

Middleware

Middleware
- JBoss: JBoss EAP,
- SOA Platform, BRMS,
- Portal, Data Services,
- vFabric Servers
- Gemfire, ERS, SQLFire
- Tomcat
Database
- EnterpriseDB: Setup,
- Migration, Cluster, DR
- MySql: Setup
- Migration, Cluster, DR
- Development

More Details




Cloud

Virtulization
- RHEV
- vSphere
- Advance Setup services for fault-tolerance
- High availability DR setup
Cloud
- CloudForms,
- Openshift,
- vCloud Family,
- Amazon Cloud: EC2,
- S3, Content Delivery Network,
- Openstack, OpenQRM,
- Cloud.com

More Details