Welcome to another deep dive. Today. We're gonna be tackling Jakarta E security, okay, and you know this is a big topic. Yeah, so we're gonna be looking at the history, the core concepts, and you know how it all actually works in practice.
Sounds good.
You've been kind enough to share with us the definitive Guide to Security in Jakarta Ee. Yeah. And just glancing at the cover, it's beautifully designed.
Oh.
It is by E Studio Kalamar and the image is from Vincent law on unsplash.
Nice.
Really speaks to the collaborative spirit of Jakarta E.
It does.
But enough about the aesthetics. Let's get into the nuts and bolts of Jakarti E security. We're going to uncover some surprising history along the way and really look at how it functions in the real world.
Looking forward to.
So to kick things off, maybe you can take us back in time a little bit too, those early days of Java when security wasn't really top of mind.
Yeah. Well, going back to the late nineteen nineties, Java applications were just starting to become more complex and the need for security became a but it wasn't really a primary concern when Java was first design.
So it's kind of like trying to add seat belts to a car after it was already built.
Yeah, exactly.
They had to kind of bolt it on later, and that led to some interesting.
Challenges they called technical debt right exactly.
And one of the first attempts to address this was JAS, the Java Authentication and Authorization Service. It actually started as an extension to Java one point three and then later became part of Java one point four.
Okay, so JAS comes on the scene. How does that initial approach to security shape what came next.
Yeah, so JS laid the groundwork for what eventually became Jakarta Authentication. It was originally called JAOF, and jaof's aim was to standardize the way authentication worked, especially for web applications running in containers like tom Kat and JBoss, and then as JS evolved and integrated into Jakarta EE, it led to the development of Jakarta Authorization and then eventually Jakarta Security.
Gotcha. So you have this kind of progression from this initial attempt bolt on security to something more robust exactly.
But there's another really important piece of the puzzle that came from outside the Java e World. Okay, and that was an open source project called a CG security.
A CG security that rings a bell. I feel like a lot of developers I knew were really drawn to a CG. What was it about that project that sort of captured people's imaginations?
It really addressed some of the limitations of the existing Java E security mechanisms at the time.
Okay, and it was.
So popular that many of its concepts ended up being incorporated into jacarti E security.
So it's kind of like the indie band that gets so popular it goes mainstream exactly. Okay. So we have this infusion of ideas from a CIG How does that really impact the jakarti E security that we know and use today.
It made jakarti E security more robust and also more developer friendly and powerful.
So this history is important. Understanding this history helps us understand how we got to where we are.
Definitely. Yeah, it gives us valuable insight into how it works, why it works the way it does.
Okay, history lesson aside. Let's be honest, security can be a bit of a maze. It can, especially with all the jargon. Yeah, so maybe before we dive too deep, let's define some key terms just so we're all on the same page. Sure, So when we talk about security, what are some of those fundamental concepts that we really need to grasp.
Well, a great place to start is with what's known as the CIA triad, confidentiality, integrity, and availability.
The CIA triad.
These are like the fundamental principles of information security, right, and they kind of go hand in hand. So confidentiality that means that sensitive information is only accessible to those authorized to see it makes sense. Integrity means that the data hasn't been tampered with and it remains accurate. And then availability ensures that authorized users can access the information when they need it.
Of those three, confidentiality, integrity, and availability, which one do you think is the most challenging to kind of maintain in today's environment where we've got all these inner connected systems and applications.
That's a tough one. They each have their own unique challenges, but I think availability is probably the most difficult to guarantee.
Okay, so availability meaning keeping the systems up and running accessible.
Exactly because there's so much reliance on cloud services and interconnected systems that if you have a single point of failure that can have cascading effects and impact the availability of critical applications and data.
That makes sense. Now, let's clear up another common point of confusion. What about authentication versus authorization? Okay, yeah, what are the key differences there?
So authentication is about verifying your identity? Right, are you who you claim to be? It's like the bouncer at a club checking your ID?
Okay.
Authorization comes after authentication. So once your identity has been verified, what are you allowed to do? So? Can you enter a restricted area? Can you access specific files? That's authorization in action.
So it's like a two step process. Prove who you are and then what you can do?
Right?
Okay, now within your car to eth These concepts are further refined through what are called principles and roles. What are those?
So a principle is basically any entity that can be authenticated. But it could be a user, it could be a system, it could even be a device. And then rolls are used to group principles with similar permissions. Okay, So for example, you might have an admin role that has access to system settings and a user role that has more limited access.
Right, So you're basically categorizing users or systems based on the level of access they should have exactly. All right, now, let's talk about the classic ways to kind of prove who you are. Classic something you know, like a password, right.
Or something you have like a token or a security a key, and.
Then the more modern approach something you are like a fingerprint or a facial scam.
Yeah, biometrics.
So what are some of the trade offs that developers need to consider when choosing between these different authentication methods.
Well, each approach has its strength weaknesses. Passwords are convenient but vulnerable to attacks. Biometrics are more secure, but they can raise privacy concerns.
It's always a trade off, right, security versus convenience, security versus privacy Exactly. You have to find the right balance.
Yeah.
Now, we've been talking about these different ways to authenticate, but Jakarta E also supports two main approaches to implementing security, declarative and programmatic. Right, what are those and maybe what are some of the trade offs there?
Yeah, So declarative security is all about setting rules through configuration files or annotations. Okay, It's a really streamlined approach that works well for common security scenarios.
It's kind of like having a pre configured security system in place.
Exactly, just set the settings and go yeah.
And then programmatic security, on the other hand, gives developers more control and flexibility because they can write code to enforce specific security rules. So which one you choose kind of depends on the complexity of your application and how much customimization you need.
Right. So, declarative is sort of like you know, off the shelf, and programmatic is more like building your own customs solution exactly, right. So we've laid some groundwork, we've defined some key terms, we've looked at the evolution of security and Java. In part two of our deep dive, we're going to start really digging into the specifics of Jakarta authentication and Jakarta authorization.
Great, can't wait, Stay tuned. Now, let's dive into Jakarta authentication, which is all about verifying those identities acting as the gatekeeper for our applications. Right, and we'll focus here on the servelet container profile, a key piece for web applications.
So, how does Jakarta authentication work with those you know, those old workhorses, those servelet containers like Tomcat and JBoss.
It integrates seamlessly with them, leveraging the container's existing security mechanisms to provide that robust authentication framework.
Right. So it's working with the container, not against it, exactly. Okay, So walk us through how this authentication process actually unfolds. Sure, what are the steps involved?
So imagine a user is trying to access a protected resource, right, their browser is going to send a request to the server. The server then checks if that resource requires authentication.
And if it does.
If it does, then the authentication mechanism kicks in. Okay, and this is where the server ofth module comes into play.
Okay, So server off module this sounds like a pretty important piece of the puzzle.
It is. Yeah, what role does it.
Play in this whole process?
The server off module is really at the heart of JA card authentication.
Okay.
It's highly configurable. It acts as a plug in point for custom authentication logic, so it's.
Like a specialist security guard you can train to follow specific rules for your application exactly. So the server off module could interact with a database to validate user credentials or even connect to some external identity provider exactly.
And it can use various callbacks to gather information from the user the user name and password, and then validate those credentials against an identity store.
Okay, so we've authenticated our user right now, what how does Jakarta authorization step in to figure out what they can do what they can access.
So, Jakarta authorization focuses on fine grained access control. It takes the security constraints that are defined in your web dot XML or through annotations and translates those into concrete permissions that can be checked at run time.
So it's kind of like enforcing those rules about who can access what within the application precisely.
Okay, Like if you have an admin dashboard that should only be accessible to users with the admin role, Jakarta authorization would enforce.
That rule, gotcha. So it's making sure that only the right people get to see that admin dashboard exactly. Okay. That's pretty powerful, that ability to kind of control access at that level.
It is.
Now, what about those situations that require more complex rules, more than just those simple role based checks. Can Jakarta authorization handle that kind of nuance?
It can? Yeah, Okay, you can create custom authorization modules to implement more intricate authorization logic.
So for those really edge cases. Exactly, you've got that flexibility. Yeah, okay, good to know. Now, let's shift gears a little bit and top of Jakarta security and how it aims to make life a little easier for developers. Yeah, I understand. It provides this kind of higher level API that sits on top of Jakarta authentication and Jakarta authorization.
It does the thinking there.
It just streamlines the whole process of implementing those common security tasks in web applications.
Okay.
You can think of it as this pre built security system with all the essential features already in place, so.
You don't have to reinvent the wheel every time you build a new application. Exactly, You've got the toolbox already there, right. Okay. So one of the key interfaces I understand in Jakarta security is the HTT authentication mechanisms. Yeah, does that do?
So that's what enables you to implement the different authentication method like basic authentication, form based authent okay, or even those custom solutions.
You know, it's funny, We've been talking about a lot of this kind of technical stuff and I just thought, you know, I'm curious, have you ever run into one of those capture things? Online where they ask you to identify the fire hydrants or the crosswalks.
Oh yeah, those CAPTCHAs, Yeah, exactly right, all the time.
It seems like they're everywhere these days. Yeah, what do you, I mean, what do you think of those?
I think they can be effective in preventing automated attacks, but they're also kind of annoying for users.
Yeah they are so I'm a human, I swear. Okay, back to Jakarta's security. We were talking about the HTT authentication mechanism, right, and how that helps developers implement those different authentication methods.
Yeah, it provides a consistent way to plug in those different mechanisms and handle the authentication flow.
Now, what about those remember me features we see on websites all the time. Oh yeah, how does Jakarta security support that kind of functionality?
So Jakarta Security allows for persistent authentication, which is a essentially the mechanism behind those remember me features.
Okay.
It enables users to stay logged in for an extended period without having to repeatedly enter their credentials.
Right, So it's convenient for the user, but it's also you know, there's some security implications there.
Right, Absolutely, you have to be very careful about how you implement that remember me functionality.
What are some best practices there? What should developers keep in mind?
So you want to make sure you're using secure token based approaches, okay, You want to implement robust token expiration mechanisms, right.
So the tokens don't last forever exactly.
Yeah, and you want to educate your users about the potential risks, especially.
About staying logged in on shared devices.
Yeah, exactly, good point.
Good point. Now, I understand that your Karda's security also integrates nicely with CDI context and dependency injection.
It does.
How does CDI help to kind of streamline the whole management of these security related components.
So CDI is kind of like the nervous system of your application. It connect the different parts and manages the dependencies. And with Jakarta security, that means easier management of those security related beans and services.
Okay, So CDI is kind of taking care of all the wiring behind the scenes, so you don't have to worry about it as much.
Exactly.
That's nice, less for the developer to worry about it. Right now, we've been talking about user initiated authentication, like when you click on a log in button. But what about those situations where it's the container that initiates the authentication, maybe to access.
A particular resource, right, Yeah, does.
Jakarta Security handle that as well?
It does. It handles both scenarios gracefully.
Okay, So whether the user wants to log in or is first to log in, Jakarta Security's got it covered.
Yeah.
It provides that comprehensive framework for handling those authentication flows in web applications.
That's great. Now, we've been focusing a lot on web applications, right, but what about Jakarta Faces. Okay, how does Jakarta Security apply in that context?
So Jakarta Security is equally relevant in Jakarta Face's applications. It allows you to control access to specific UI components or actions based on user roles and permissions.
So you can use those annotations like at roles allowed and at servelet security to kind of fine tune access control even at the level of individual UI elements precisely, so you could have a button that only certain users.
Can see, exactly, or a.
Form that only certain users can submit.
Yeah, it's very powerful in terms of protecting sensitive information and actions.
Really gives you that granular control. Yeah, okay, so we've got this comprehensive solution for managing security in both servelet based and Jakarta Faces applications.
We do.
It's quite a toolkit, it is. Now it's important to remember that security is not a one time thing. This is an ongoing process.
It is.
Yeah, to the vigilant, you have to stay.
Up to date exactly.
Staying up to date with the latest best practices and security updates is absolutely cruefl for building and maintaining secure applications.
It's a never ending battle. It is now explored a lot within the realm of Jakarta E. But let's take a step back for a moment and look at the foundations. Sure, the java SE elements that underpin all of this. All right, It's kind of like you have to understand the foundation of a skyscraper, right, Yeah, you can't just appreciate the fancy design on those top floors without knowing what's holding it.
All up exactly.
Jakarta E security wouldn't exist without those core elements from java SE, right, and understanding them gives you a much deeper appreciation for how security works at all levels.
Okay. So let's start with JA, the Java Authentication and Authorization Service. Okay, we talked about it a little bit before, but now let's look at it from that Java SE perspective.
All right. Yeah, JA is considered like the granddaddy of Java security, Okay, and it's still very relevant today.
Oh wow.
It provides this framework for implementing custom authentication logic even outside of Jakarta.
Ee.
So you mentioned these custom logan modules earlier. What exactly are those and how do they fit into JMEA module?
You can think of it as like a specialized authentication routine. So let's say you need to authenticate users against a legacy system that doesn't follow standard protocols, right, you could write a custom login module to handle that specific authentication process.
So it gives you that flexibility to adapt to unique situations exactly. Okay, that's really valuable. Now, what about cryptography. How does Java SE handle the need to protect sensitive data both when it's stored and when it's transmitted over networks.
That's where JCE comes in, the Java Cryptography Extension.
Okay.
JC it's basically your toolbox for all things cryptography, and Java.
So provides the tools that developers need to encrypt data, generate keys, implement different algorithms, all that stuff.
Exactly. JCE is a very powerful framework that supports a wide range of cryptographic operations.
Wow.
And it also allows developers to plug in different cryptographic implementations through what are called JCE providers.
Okay, JCE providers, what are those?
So let's say you need to use a specific encryption algorithm that's not provided by the default providers in the JDK. You can then incorporate an external provider like bouncy Castle, which offers a wider range of algorithms.
So it gives you that flexibility to choose the best tool for the job exactly. Okay. You know, we can't really talk about security without mentioning TLS Transport layer security, right. It's what makes secure communication over the Internet possible.
Absolutely essential for protecting data in transit.
Right. So that's what ensures that your credit card information is safe when you're shopping online, your confidential messages are protected exactly. Now. I think most people are familiar with that little padlock icon in their browser that indicates HTTPS. But what's actually happening behind the scenes to make that secure connection possible.
So TLS uses a combination of public key, cryptography and digital certificates to establish that secure channel between your browser and the web server.
Okay.
It's a process called an and shake where the two parties basically exchange cryptographic keys and verify each other's identities.
So it's making sure you're talking to the right website and that nobody's eavesdropping in the middle.
Exactly.
Okay, that makes sense. What about different versions of TLS, I know there have been several over the years.
Yeah, and it's very important to use the latest and most secure version, which is currently TL's one point three.
Okay, TLS one point three, got it.
It has significant improvements in both speed and security compared to older versions.
Good to know. Now we've covered those foundational elements in Java, se JAS, JCE, TLS. Yeah, but when we talk about managing identities on a larger scale across multiple applications, you know, entire systems, we need more sophisticated tools, right, and that's where identity management solutions come in.
Exactly. They're essential for organizations that need to manage users, roles, and permissions across a whole ecosystem of applications.
So instead of every application having its own separate security set up. You can have this kind of central system that handles authentication authorization for.
Everything exactly, which makes things much easier to manage.
Much more efficient. Yeah, so what are some popular identity management solutions that kind of build on top of those job su security foundations we talked about.
Two well known open source solutions are Shibballeth and key Cloak.
Okay, I've heard of those.
So Shibaleth it focuses on federated identity and single sign on or SSO, using the MML protocol and SSO is a great feature because it allows users to log in once.
I love single sign on.
Yeah, it's very convenient.
You log in once and you have access to all your applications exactly.
It makes things much smoother.
So how does shibaleth actually make that possible.
It relies on a trust relationship between an identity provider or IDP and service providers or sps. So the IDP handles the authentication and then the sps rely on the IDP to verify the user's identity.
So the user logs into the IDP once and then they can seamlessly act all those different sps without having to log in again.
Exactly.
That's great. Now what about key cloak. How's that different from shibbaleth So key.
Cloak is a more versatile identity management solution.
Okay.
It supports MML, but it also supports other protocols like oh OFF and open id connect.
So it's kind of like a Swiss army knife of identity management.
Yeah, you could say that.
Okay, So it's more feature rich, you can handle more scenarios.
Exactly.
What are some of its like standout features.
Well, it offers fine grained authorization, which allows you to define very specific permissions for users and roles.
Okay.
It also supports user federation, which means it can connect to various user directories.
Right like if you're using LDAP or active directory or something like that, Exactly, you can hook into that.
Yeah.
And it also provides a very user friendly administration console for managing all aspects of identity and access.
So it's really a comprehensive solution, it is. Well, you know, we've come a long way in this deep dive we have. You know, from the early days of Java when security was kind of a afterthought to these really sophisticated frameworks and tools that we have available today.
It's been quite a journey, it really has.
So I think our listeners are now equipped with a solid understanding of.
Jakarta EE security I hope so.
And the broader landscape of identity management solutions. But you know, it's important to remember this is an ongoing journey, it is security is never truly done. What do you think are some of the biggest challenges facing Jakarta E security in the years to come, and how can the community continue to address those challenges.
That's a great question. As technology evolves, you know, new threats are always emerging, right, so staying ahead of the curve requires constant vigilance, collaboration, and a commitment to continuous learning.
So we all have a part to play, we do, and making sure that our applications and our systems are secure exactly. Well, on that note, I think it's time to wrap up our deep dive into Jakarta E Secure.
It's been a pleasure.
It's been great having you here. I really appreciate you sharing your expertise with us. You're welcome, and I hope our listeners have found this exploration insightful and engaging. We too, So until next time, stay curious, and stay secure.