Authentication

🔐 Jakarta Security Authentication: The Bouncer at Your App’s Door

Imagine your web application is a super exclusive nightclub. You wouldn’t let just anyone walk in, right? You need a bouncer! Jakarta Security is that bouncer—checking IDs, remembering VIP guests, and making sure only the right people get to the right rooms.

🌟 The Big Picture: What is Jakarta Security?

Think of Jakarta Security like the security system at a fancy hotel:

• The front desk checks if you’re a guest (Authentication)
• Your room key only opens YOUR room (Authorization)
• The security cameras remember who went where (Security Context)

graph TD
    A["🧑 User Arrives"] --> B{🔐 Security Check}
    B -->|Valid ID| C["✅ Welcome In!"]
    B -->|Invalid ID| D["❌ Access Denied"]
    C --> E["🎯 Access Resources"]

Why Does This Matter?

Without Jakarta Security, your app is like a house with no locks. Anyone could:

• Pretend to be someone else
• Access private information
• Do things they shouldn’t

🎭 Security Context: The Memory of Your Bouncer

What is Security Context?

Imagine your bouncer has a magic notebook that remembers:

• Who you are
• What groups you belong to
• Whether you’re currently logged in

That’s the Security Context! It holds all the security information about the current user.

Real Example

@Inject
SecurityContext securityContext;

public void checkAccess() {
    // Is someone logged in?
    Principal user = securityContext
        .getCallerPrincipal();

    // What's their name?
    String name = user.getName();

    // Are they a manager?
    boolean isManager = securityContext
        .isCallerInRole("MANAGER");
}

Think of it like this:

👤 Caller Principal: Your Digital ID Card

The Simple Truth

Caller Principal = The logged-in user’s identity

Just like your driver’s license has your name and photo, the Caller Principal contains:

• Name: Who you are
• Type: How you proved it

Picture This

┌─────────────────────────────┐
│     🪪 CALLER PRINCIPAL      │
├─────────────────────────────┤
│  Name: alice@example.com    │
│  Type: FormAuthentication   │
│  Valid: ✅ Yes              │
└─────────────────────────────┘

Code Example

// Get the current user's identity
Principal caller = securityContext
    .getCallerPrincipal();

if (caller != null) {
    System.out.println(
        "Hello, " + caller.getName()
    );
} else {
    System.out.println(
        "Please log in first!"
    );
}

🚪 Authentication Mechanisms: Different Ways to Show ID

The Four Ways to Prove Who You Are

Think of these as different types of ID you could show:

graph TD
    A["🔑 Authentication<br>Mechanisms"] --> B["📋 Basic Auth"]
    A --> C["📝 Form-Based"]
    A --> D["🛠️ Custom Auth"]
    A --> E["🌐 OpenID Connect"]

📋 Basic Authentication: The Quick ID Flash

What is it?

Basic Auth is the simplest way. It’s like:

1. The bouncer asks: “Username and password?”
2. You tell them
3. They let you in (or not)

How It Works

┌──────────────────────────────────────┐
│  Browser sends:                      │
│  Authorization: Basic YWxpY2U6MTIz  │
│                                      │
│  (That's "alice:123" encoded)        │
└──────────────────────────────────────┘

Setting It Up

@BasicAuthenticationMechanismDefinition(
    realmName = "my-realm"
)
@ApplicationScoped
public class AppConfig {
    // That's it! Basic auth enabled!
}

⚠️ Important Warning

Basic Auth sends passwords in a way that’s easy to read. ALWAYS use HTTPS!

Think of it like whispering your password vs shouting it. HTTPS = whisper.

📝 Form-Based Authentication: The Guest Registration

What is it?

Instead of shouting your password, you fill out a nice form. The bouncer:

1. Shows you a login page
2. You type username/password
3. They check and remember you

The Magic Flow

graph TD
    A["🧑 Visit Protected Page"] --> B["📄 Redirect to Login"]
    B --> C["✏️ Fill Login Form"]
    C --> D{🔍 Check Credentials}
    D -->|✅ Valid| E["🎉 Access Granted"]
    D -->|❌ Invalid| F["😞 Try Again"]

Setting It Up

@FormAuthenticationMechanismDefinition(
    loginToContinue = @LoginToContinue(
        loginPage = "/login.html",
        errorPage = "/error.html"
    )
)
@ApplicationScoped
public class AppConfig {
    // Form auth ready!
}

Your Login Form

<form method="POST"
      action="j_security_check">

    <input type="text"
           name="j_username">

    <input type="password"
           name="j_password">

    <button type="submit">
        Login
    </button>
</form>

Why j_username and j_password?

These are magic names that Jakarta Security looks for. Like a secret handshake!

🛠️ Custom Authentication: Build Your Own Bouncer

When Do You Need This?

Sometimes the standard methods don’t fit:

• You want fingerprint login
• You need to check a special database
• You want two-factor authentication

The Recipe

1. Implement HttpAuthenticationMechanism
2. Define your logic
3. Register it with @ApplicationScoped

Example: API Key Authentication

@ApplicationScoped
public class ApiKeyAuth
    implements HttpAuthenticationMechanism {

    @Override
    public AuthenticationStatus
        validateRequest(
            HttpServletRequest request,
            HttpServletResponse response,
            HttpMessageContext context) {

        // Get API key from header
        String apiKey = request
            .getHeader("X-API-Key");

        // Check if valid
        if (isValidApiKey(apiKey)) {
            return context.notifyContainerAboutLogin(
                new ApiKeyPrincipal(apiKey),
                Set.of("USER")
            );
        }

        // Not valid!
        return context
            .responseUnauthorized();
    }
}

Think of it like:

Standard Auth = Buying clothes at a store
Custom Auth = Making your own clothes

More work, but fits PERFECTLY!

🌐 OpenID Connect: “Google/Facebook Said I’m OK!”

The Everyday Example

Ever clicked “Login with Google”? That’s OpenID Connect!

Instead of creating yet another password, you use an account you already have.

How It Works (Simple Version)

graph TD
    A["🧑 Click Login with Google"] --> B["🔄 Redirect to Google"]
    B --> C["✏️ Enter Google Password"]
    C --> D["✅ Google Says OK"]
    D --> E["🔙 Return to App"]
    E --> F[🎉 You're Logged In!]

The Players

Setting It Up

@OpenIdAuthenticationMechanismDefinition(
    providerURI =
        "https://accounts.google.com",
    clientId = "your-client-id",
    clientSecret = "your-secret",
    redirectURI =
        "${baseURL}/callback"
)
@ApplicationScoped
public class AppConfig {
    // OpenID Connect ready!
}

Why is This Awesome?

1. Users don’t create another password (fewer passwords to forget!)
2. You don’t store passwords (less risk!)
3. Google/etc handles the hard stuff (less work!)

🎯 Putting It All Together

The Complete Picture

graph TD
    subgraph "Jakarta Security"
        A["Security Context"] --> B["Caller Principal"]
        C["Auth Mechanisms"] --> D["Basic"]
        C --> E["Form"]
        C --> F["Custom"]
        C --> G["OpenID"]
    end

    H["🧑 User"] --> C
    C --> A
    A --> I["🔓 Protected Resources"]

Quick Comparison

*With HTTPS, Basic becomes secure!

🚀 Key Takeaways

1. Jakarta Security = Your app’s bouncer
2. Security Context = The bouncer’s memory
3. Caller Principal = Your digital ID
4. Basic Auth = Quick and simple
5. Form Auth = Pretty login pages
6. Custom Auth = Build what you need
7. OpenID Connect = Let Google be the bouncer

💡 Remember This!

Authentication is about proving WHO you are. Authorization is about WHAT you can do. Jakarta Security handles both!

🔑 + 🚪 = 🎉
(Credentials + Auth Mechanism = Access!)

You’ve got this! Jakarta Security might seem complex, but it’s just a fancy bouncer doing its job. Once you understand the bouncer, you understand security! 🎉