spect Declarative Security Programmatic Security

Security constraints and

configurations are specified

Security logic is implemented within the
Definition outside of the application code,
application code itself.
typically in deployment

descriptors.

Done via XML configuration files Done using API calls within the code, e.g., using

Configuration like web.xml or annotations like HttpServletRequest.isUserInRole() in

@RolesAllowed. servlets.

Flexibility and Less flexible as it relies on More flexible and dynamic since it allows

Control predefined configurations. fine-grained control within the code.

Generally easier to implement

Requires more careful coding and management,
and manage, as it doesn't require
Ease of Use as security checks are part of the application
coding security checks directly in
logic.
the application logic.

Suitable for straightforward and

Best for complex or highly dynamic security
standard security requirements
Use Cases requirements that can't be easily represented in
that align with the provided
declarative configuration.
declarative options.

High, as the security Lower, as changes in the application code might

Portability configurations are handled by be required when moving between different

the Jakarta EE container. Jakarta EE environments.

 Defining role-based access
Implementing custom authentication logic or
Examples control in web.xml or using
dynamic role checks in the application code.
annotations like @DeclareRoles.

Easier to maintain as changes in

Requires changes in the application code, which
security requirements often only
Maintenance might involve more extensive testing and
require changes in configuration
redeployment.
files or annotations.

Generally coarse-grained, applied

Fine-grained, can vary within a component based
Granularity uniformly to components or
on runtime decisions.
URLs.

Often reliant on the container's

Integration with Allows for custom integration logic within the
capabilities for integration with
External Systems application, facilitating complex integrations.
external security systems.

Applications with standard

Typical Application Applications with dynamic security requirements
security requirements, such as
Scenarios or the need for custom security logic.
role-based access control.
 Concept Description Example

A realm in Jakarta EE security is a "security CorporateRealm: A realm for a corporate

Realms policy domain" that manages a set of users application, handling the security for company

and groups. users.

Users are individual accounts or identities

Users User1: John Doe<br>User2: Jane Smith
within the realm.

Groups categorize users, usually based on

Groups Group1: Sales<br>Group2: IT Support
their job function or department.

Roles are assigned to groups or users to Role for Group1 (Sales): Access to sales

Roles define their permissions and access levels data<br>Role for Group2 (IT Support): Admin

in the app. access

Realm Description

file Uses file-based authentication; user credentials are stored in a file (e.g., keyfile).

admin-realm Used for securing the GlassFish Server administration console.

 certificate Handles client certificate authentication.

1. Example for the 'file' Realm:

Type Definition Example

Individual accounts in the

User User1: john<br>User2: jane
realm.

Group Categorization of users. Group1: admins<br>Group2: developers

Permissions assigned to Role for admins: full access to server resources<br>Role for
Role
groups or users. developers: limited access to development resources

​ Principal:
● Definition: A principal typically represents an entity (like a user, device, or
system) that can be authenticated in a security system. In most cases, a
principal is identified by its unique name or identifier.
● Example: Consider a user named "Alice." In a computer system, "Alice" is
the principal. It's her unique identity in the system, distinguishing her from
other users.
​ Credential:
 ● Definition: A credential is a piece of information or data that is used to
verify the identity of a principal. It's something that the principal knows or
possesses, which can be used to prove their identity.
● Example: If Alice's account is protected by a password, that password is
her credential. When she logs in, she provides her username ("Alice" - the
principal) and her password (the credential) to prove that she is indeed
Alice.

To put it in a simple real-world analogy:

● Think of a principal as your name (like your identity card) which identifies who
you are.
● A credential is like the PIN to your ATM card; it's a secret that proves the card
belonging to your name is being used by you.
 Usage in

Annotation/Method Description Session Beans Example

Applied at the

Used to declare security class level of a

roles. It's a class-level session bean to

@DeclareRoles({"Admin", "User"})
@DeclareRoles annotation that declares declare the
public class MySessionBean { ... }
the roles used by the roles that are

application. used within the

bean.

Applied at the

class or method

level. If at the

Specifies which security class level, it

roles are allowed to applies to all @RolesAllowed("Admin") public void

@RolesAllowed
access methods in a methods; if at adminOnlyMethod() { ... }

session bean. the method

level, it applies

only to that

method.

Applied at the

Indicates that no security method level to

@DenyAll public void
@DenyAll roles are allowed to explicitly deny
noAccessMethod() { ... }
access the method. access to all

callers.
 Applied at the

class or method

level. If at the

class level, it
Indicates that all security
applies to all @PermitAll public void
@PermitAll roles are allowed to
methods; if at openAccessMethod() { ... }
access the method.
the method

level, it applies

only to that

method.

Used within a

session bean

A method that returns method to get public void someMethod() {

the the principal of Principal caller =
getCallerPrincipal()
java.security.Princip the caller. sessionContext.getCallerPrincipa

al of the caller. l(); ... }

Useful for audit

or tracking

purposes.

Used within a

session bean
A method that checks if public void someMethod() { if
isCallerInRole(String method to
the caller belongs to a (sessionContext.isCallerInRole("
roleName) check if the
specific security role. Admin")) {
caller has a

certain role.
1. Encryption
Usage Scenario: When you need to securely transmit or store data so that only
authorized parties can access the original content.

● Description: Convert plaintext (readable format) to ciphertext (encoded format)

using a key.

2. Cryptographic Hashing
Usage Scenario: When verifying data integrity or storing passwords.

● Description: Convert data into a fixed-size hash. The process is one-way and the
original data can't be retrieved from the hash.

3. Symmetric Key Encryption

Usage Scenario: When the same entity is encrypting and decrypting, or when there's a
secure way to share the key.

● Description: Use the same key for both encryption and decryption. Common
algorithms include AES.

4. Asymmetric Key Encryption

Usage Scenario: In scenarios where secure key exchange is challenging, like in Internet
communications.

● Description: Use two keys - a public key for encryption and a private key for
decryption. Common algorithms include RSA.
5. Generating KeyPair in Java SE
Usage Scenario: When setting up asymmetric encryption.

● Description: Generate a public/private key pair using an algorithm like RSA.

6. Using KeyPair in Java SE for Performing Asymmetric Key

Encryption
Usage Scenario: For encrypting data that can only be decrypted by the intended
recipient.

● Description: Encrypt data with the recipient's public key. The recipient then
decrypts it with their private key.

7. Combining Asymmetric Encryption with Cryptographic

Hashing
Usage Scenario: For creating digital signatures or when extra security is required.

● Description: First, hash the data. Then, encrypt the hash with a private key (digital
signing).

8. Performing Cryptographic Hashing in Java SE

Usage Scenario: When storing user credentials or ensuring data integrity.

● Description: Convert data (like passwords) to a hash using algorithms like

SHA-256.

9. Performing Symmetric Key Encryption in Java SE

Usage Scenario: For fast encryption of data where the same party is encrypting and
decrypting.

● Description: Encrypt and decrypt data using the same key, managed securely.
10. Salted Message Digest of Password
Usage Scenario: For securely storing user passwords.

● Description: Add random data (salt) to passwords before hashing to enhance

security.

11. Cipher Text of Credit Card Details

Usage Scenario: When storing or transmitting sensitive information like credit card
numbers.

● Description: Encrypt credit card details before storing or sending. Use either
symmetric or asymmetric encryption based on the context.