Explain EBS Security Fundamentals: SSO, SSL, and Data Encryption in Oracle Applications

Responsibilities and MOAC secure the application. These are the layers underneath. TLS on every hop. The browser-to-web-tier leg is usually encrypted. The

All topics

57 / 60

Adminintermediate

EBS Security Fundamentals: SSO, SSL, and Data Encryption

Explain the core security layers protecting an EBS environment beyond application-level responsibility security

Responsibilities and MOAC secure the application. These are the layers underneath.

Layered EBS security is like protecting a bank building: encrypted communication channels (SSL) are like secure, sealed courier pouches for documents moving between branches; SSO/OAM is like a single unified ID badge system for all bank buildings rather than separate keys for every door; and TDE is like ensuring even if someone steals a physical filing cabinet (storage media), its contents remain locked and unreadable without the proper key.

Key Concepts

TLS on every hop.

    browser  --TLS-->  web tier  --?-->  application tier
             --?-->  database

The browser-to-web-tier leg is usually encrypted. The application-to-database leg often is not, and it carries the same data plus credentials.

Oracle Net native encryption or TLS handles that leg, and it matters most where the tiers are on different networks — which is common in cloud-hosted EBS.

Single sign-on removes EBS-specific passwords. Through Oracle Access Manager or a SAML identity provider, authentication moves to the enterprise's identity system.

    with SSO      one account, one password policy, one place to
                  disable somebody
    without SSO   an EBS password per user, managed separately

The security argument is deprovisioning, more than convenience. Somebody leaves, their central account is disabled, and their EBS access ends with it.

Without SSO, EBS is another system where a leaver's account survives until an administrator remembers it — which is one of the most common findings in any access audit.

Encryption at rest through Transparent Data Encryption protects the data files and backups. It defends against the stolen disk and the copied backup, and it does nothing against an authorised user querying the data, which is what the application layer is for.

The layers, and what each actually defends against.

    responsibilities / MOAC   what an authenticated user may reach
    SSO                       who is authenticated at all
    TLS                       reading traffic in transit
    TDE                       reading the files or a backup
    database auditing         what was actually done

They do not substitute for each other. TDE on a system where every user holds a broad responsibility protects the disk and nothing else.

One practical note. Enabling TLS between the tiers is a configuration change with a performance cost and a certificate lifecycle. Certificates expire, and an expired one between the application and database tiers takes the system down — which is an argument for monitoring expiry, not for skipping the encryption.

What the interviewer is probing.1. "How is single sign-on implemented for EBS?" Probing: the architecture. Stalls: "A login page." Moves up: through Oracle Access Manager with the EBS AccessGate, which links the external identity to the FND user.

2. "What is the encryption story?" Probing: the breadth. Stalls: "Passwords are hashed." Moves up: TLS in transit, transparent data encryption for data at rest, and dedicated encryption for credit card data in the payments module.

3. "What are the common audit findings?" Probing: the practical angle. Stalls: "None." Moves up: default accounts still enabled, over-broad responsibilities, no password policy, and generic shared accounts with no accountability.

4. "What is the first thing you would check on a new instance?" Probing: the instinct. Stalls: "The firewall." Moves up: default and seeded account passwords, and whether the instance is reachable from the internet at all.