WEBVTT 1 00:00:00.080 --> 00:00:03.279 Welcome to another deep dive. Today. We're gonna be tackling 2 00:00:03.600 --> 00:00:07.759 Jakarta E security, okay, and you know this is a 3 00:00:07.799 --> 00:00:10.160 big topic. Yeah, so we're gonna be looking at the history, 4 00:00:10.359 --> 00:00:13.480 the core concepts, and you know how it all actually 5 00:00:13.560 --> 00:00:14.400 works in practice. 6 00:00:14.480 --> 00:00:15.000 Sounds good. 7 00:00:15.519 --> 00:00:18.079 You've been kind enough to share with us the definitive 8 00:00:18.120 --> 00:00:21.239 Guide to Security in Jakarta Ee. Yeah. And just glancing 9 00:00:21.280 --> 00:00:23.280 at the cover, it's beautifully designed. 10 00:00:23.440 --> 00:00:23.640 Oh. 11 00:00:23.679 --> 00:00:27.199 It is by E Studio Kalamar and the image is 12 00:00:27.199 --> 00:00:29.239 from Vincent law on unsplash. 13 00:00:29.359 --> 00:00:29.719 Nice. 14 00:00:30.199 --> 00:00:33.079 Really speaks to the collaborative spirit of Jakarta E. 15 00:00:33.320 --> 00:00:33.799 It does. 16 00:00:34.359 --> 00:00:36.960 But enough about the aesthetics. Let's get into the nuts 17 00:00:36.960 --> 00:00:40.119 and bolts of Jakarti E security. We're going to uncover 18 00:00:40.200 --> 00:00:42.880 some surprising history along the way and really look at 19 00:00:42.920 --> 00:00:44.320 how it functions in the real world. 20 00:00:44.439 --> 00:00:45.159 Looking forward to. 21 00:00:45.240 --> 00:00:47.000 So to kick things off, maybe you can take us 22 00:00:47.000 --> 00:00:49.640 back in time a little bit too, those early days 23 00:00:49.640 --> 00:00:52.600 of Java when security wasn't really top of mind. 24 00:00:53.320 --> 00:00:55.600 Yeah. Well, going back to the late nineteen nineties, Java 25 00:00:55.640 --> 00:00:58.759 applications were just starting to become more complex and the 26 00:00:58.799 --> 00:01:01.079 need for security became a but it wasn't really a 27 00:01:01.119 --> 00:01:03.159 primary concern when Java was first design. 28 00:01:03.479 --> 00:01:05.200 So it's kind of like trying to add seat belts 29 00:01:05.239 --> 00:01:06.879 to a car after it was already built. 30 00:01:07.040 --> 00:01:07.599 Yeah, exactly. 31 00:01:07.640 --> 00:01:09.439 They had to kind of bolt it on later, and 32 00:01:09.480 --> 00:01:10.959 that led to some interesting. 33 00:01:10.680 --> 00:01:12.920 Challenges they called technical debt right exactly. 34 00:01:13.879 --> 00:01:16.840 And one of the first attempts to address this was JAS, 35 00:01:16.879 --> 00:01:21.319 the Java Authentication and Authorization Service. It actually started as 36 00:01:21.319 --> 00:01:24.239 an extension to Java one point three and then later 37 00:01:24.280 --> 00:01:25.879 became part of Java one point four. 38 00:01:26.000 --> 00:01:29.519 Okay, so JAS comes on the scene. How does that 39 00:01:29.719 --> 00:01:33.400 initial approach to security shape what came next. 40 00:01:33.840 --> 00:01:37.560 Yeah, so JS laid the groundwork for what eventually became 41 00:01:37.680 --> 00:01:42.159 Jakarta Authentication. It was originally called JAOF, and jaof's aim 42 00:01:42.599 --> 00:01:45.760 was to standardize the way authentication worked, especially for web 43 00:01:45.760 --> 00:01:49.319 applications running in containers like tom Kat and JBoss, and 44 00:01:49.359 --> 00:01:52.799 then as JS evolved and integrated into Jakarta EE, it 45 00:01:52.920 --> 00:01:55.719 led to the development of Jakarta Authorization and then eventually 46 00:01:55.799 --> 00:01:56.760 Jakarta Security. 47 00:01:56.879 --> 00:01:58.879 Gotcha. So you have this kind of progression from this 48 00:01:59.000 --> 00:02:02.640 initial attempt bolt on security to something more robust exactly. 49 00:02:02.680 --> 00:02:05.159 But there's another really important piece of the puzzle that 50 00:02:05.200 --> 00:02:08.360 came from outside the Java e World. Okay, and that 51 00:02:08.439 --> 00:02:11.280 was an open source project called a CG security. 52 00:02:11.560 --> 00:02:14.360 A CG security that rings a bell. I feel like 53 00:02:14.400 --> 00:02:16.319 a lot of developers I knew were really drawn to 54 00:02:16.360 --> 00:02:20.560 a CG. What was it about that project that sort 55 00:02:20.560 --> 00:02:22.280 of captured people's imaginations? 56 00:02:22.520 --> 00:02:25.879 It really addressed some of the limitations of the existing 57 00:02:25.960 --> 00:02:28.240 Java E security mechanisms at the time. 58 00:02:28.400 --> 00:02:29.199 Okay, and it was. 59 00:02:29.159 --> 00:02:32.240 So popular that many of its concepts ended up being 60 00:02:32.280 --> 00:02:34.400 incorporated into jacarti E security. 61 00:02:34.479 --> 00:02:35.960 So it's kind of like the indie band that gets 62 00:02:35.960 --> 00:02:38.599 so popular it goes mainstream exactly. Okay. So we have 63 00:02:38.680 --> 00:02:41.560 this infusion of ideas from a CIG How does that 64 00:02:41.639 --> 00:02:45.000 really impact the jakarti E security that we know and 65 00:02:45.120 --> 00:02:45.639 use today. 66 00:02:45.719 --> 00:02:49.280 It made jakarti E security more robust and also more 67 00:02:49.319 --> 00:02:51.120 developer friendly and powerful. 68 00:02:51.400 --> 00:02:54.719 So this history is important. Understanding this history helps us 69 00:02:54.759 --> 00:02:56.319 understand how we got to where we are. 70 00:02:56.479 --> 00:02:59.479 Definitely. Yeah, it gives us valuable insight into how it works, 71 00:02:59.479 --> 00:03:00.599 why it works the way it does. 72 00:03:00.680 --> 00:03:04.919 Okay, history lesson aside. Let's be honest, security can be 73 00:03:04.960 --> 00:03:07.319 a bit of a maze. It can, especially with all 74 00:03:07.319 --> 00:03:10.280 the jargon. Yeah, so maybe before we dive too deep, 75 00:03:10.560 --> 00:03:13.319 let's define some key terms just so we're all on 76 00:03:13.360 --> 00:03:17.560 the same page. Sure, So when we talk about security, 77 00:03:17.599 --> 00:03:20.080 what are some of those fundamental concepts that we really 78 00:03:20.120 --> 00:03:21.159 need to grasp. 79 00:03:21.000 --> 00:03:23.080 Well, a great place to start is with what's known 80 00:03:23.080 --> 00:03:26.919 as the CIA triad, confidentiality, integrity, and availability. 81 00:03:27.039 --> 00:03:27.960 The CIA triad. 82 00:03:28.039 --> 00:03:31.000 These are like the fundamental principles of information security, right, 83 00:03:31.159 --> 00:03:34.080 and they kind of go hand in hand. So confidentiality 84 00:03:34.120 --> 00:03:37.560 that means that sensitive information is only accessible to those 85 00:03:38.240 --> 00:03:41.719 authorized to see it makes sense. Integrity means that the 86 00:03:41.840 --> 00:03:44.719 data hasn't been tampered with and it remains accurate. And 87 00:03:44.759 --> 00:03:49.199 then availability ensures that authorized users can access the information 88 00:03:49.240 --> 00:03:49.919 when they need it. 89 00:03:50.400 --> 00:03:55.000 Of those three, confidentiality, integrity, and availability, which one do 90 00:03:55.039 --> 00:03:57.599 you think is the most challenging to kind of maintain 91 00:03:58.159 --> 00:04:00.599 in today's environment where we've got all these inner connected 92 00:04:00.719 --> 00:04:02.000 systems and applications. 93 00:04:02.879 --> 00:04:05.919 That's a tough one. They each have their own unique challenges, 94 00:04:05.960 --> 00:04:10.319 but I think availability is probably the most difficult to guarantee. 95 00:04:10.479 --> 00:04:14.840 Okay, so availability meaning keeping the systems up and running accessible. 96 00:04:14.439 --> 00:04:18.120 Exactly because there's so much reliance on cloud services and 97 00:04:18.199 --> 00:04:20.639 interconnected systems that if you have a single point of 98 00:04:20.680 --> 00:04:24.120 failure that can have cascading effects and impact the availability 99 00:04:24.120 --> 00:04:25.759 of critical applications and data. 100 00:04:26.079 --> 00:04:28.560 That makes sense. Now, let's clear up another common point 101 00:04:28.560 --> 00:04:33.439 of confusion. What about authentication versus authorization? Okay, yeah, what 102 00:04:33.439 --> 00:04:34.519 are the key differences there? 103 00:04:34.560 --> 00:04:39.319 So authentication is about verifying your identity? Right, are you 104 00:04:39.879 --> 00:04:42.199 who you claim to be? It's like the bouncer at 105 00:04:42.240 --> 00:04:43.319 a club checking your ID? 106 00:04:43.639 --> 00:04:44.000 Okay. 107 00:04:44.120 --> 00:04:49.319 Authorization comes after authentication. So once your identity has been verified, 108 00:04:49.720 --> 00:04:53.519 what are you allowed to do? So? Can you enter 109 00:04:53.560 --> 00:04:57.720 a restricted area? Can you access specific files? That's authorization 110 00:04:57.920 --> 00:04:58.319 in action. 111 00:04:58.480 --> 00:05:00.920 So it's like a two step process. Prove who you 112 00:05:00.959 --> 00:05:02.160 are and then what you can do? 113 00:05:02.360 --> 00:05:02.639 Right? 114 00:05:02.759 --> 00:05:06.399 Okay, now within your car to eth These concepts are 115 00:05:06.439 --> 00:05:10.279 further refined through what are called principles and roles. What 116 00:05:10.360 --> 00:05:10.720 are those? 117 00:05:10.959 --> 00:05:14.720 So a principle is basically any entity that can be authenticated. 118 00:05:15.000 --> 00:05:16.879 But it could be a user, it could be a system, 119 00:05:16.920 --> 00:05:19.759 it could even be a device. And then rolls are 120 00:05:19.839 --> 00:05:24.279 used to group principles with similar permissions. Okay, So for example, 121 00:05:24.279 --> 00:05:26.199 you might have an admin role that has access to 122 00:05:26.240 --> 00:05:29.480 system settings and a user role that has more limited access. 123 00:05:29.680 --> 00:05:33.600 Right, So you're basically categorizing users or systems based on 124 00:05:33.720 --> 00:05:36.399 the level of access they should have exactly. All right, now, 125 00:05:36.439 --> 00:05:38.879 let's talk about the classic ways to kind of prove 126 00:05:38.920 --> 00:05:43.279 who you are. Classic something you know, like a password, right. 127 00:05:43.240 --> 00:05:45.480 Or something you have like a token or a security 128 00:05:45.480 --> 00:05:46.199 a key, and. 129 00:05:46.160 --> 00:05:48.839 Then the more modern approach something you are like a 130 00:05:48.839 --> 00:05:50.399 fingerprint or a facial scam. 131 00:05:50.519 --> 00:05:51.439 Yeah, biometrics. 132 00:05:51.519 --> 00:05:53.600 So what are some of the trade offs that developers 133 00:05:53.600 --> 00:05:57.720 need to consider when choosing between these different authentication methods. 134 00:05:58.120 --> 00:06:02.360 Well, each approach has its strength weaknesses. Passwords are convenient 135 00:06:02.600 --> 00:06:06.279 but vulnerable to attacks. Biometrics are more secure, but they 136 00:06:06.360 --> 00:06:07.879 can raise privacy concerns. 137 00:06:08.000 --> 00:06:10.839 It's always a trade off, right, security versus convenience, security 138 00:06:10.920 --> 00:06:13.199 versus privacy Exactly. You have to find the right balance. 139 00:06:13.399 --> 00:06:13.800 Yeah. 140 00:06:13.920 --> 00:06:17.160 Now, we've been talking about these different ways to authenticate, 141 00:06:18.399 --> 00:06:25.120 but Jakarta E also supports two main approaches to implementing security, 142 00:06:25.120 --> 00:06:29.079 declarative and programmatic. Right, what are those and maybe what 143 00:06:29.120 --> 00:06:30.360 are some of the trade offs there? 144 00:06:30.439 --> 00:06:33.399 Yeah, So declarative security is all about setting rules through 145 00:06:33.439 --> 00:06:37.639 configuration files or annotations. Okay, It's a really streamlined approach 146 00:06:37.720 --> 00:06:40.079 that works well for common security scenarios. 147 00:06:40.160 --> 00:06:42.519 It's kind of like having a pre configured security system 148 00:06:42.560 --> 00:06:43.240 in place. 149 00:06:43.079 --> 00:06:45.439 Exactly, just set the settings and go yeah. 150 00:06:45.480 --> 00:06:49.160 And then programmatic security, on the other hand, gives developers 151 00:06:49.199 --> 00:06:52.240 more control and flexibility because they can write code to 152 00:06:52.399 --> 00:06:57.040 enforce specific security rules. So which one you choose kind 153 00:06:57.079 --> 00:06:59.480 of depends on the complexity of your application and how 154 00:06:59.560 --> 00:07:01.079 much customimization you need. 155 00:07:01.480 --> 00:07:03.800 Right. So, declarative is sort of like you know, off 156 00:07:03.839 --> 00:07:06.959 the shelf, and programmatic is more like building your own 157 00:07:07.000 --> 00:07:10.399 customs solution exactly, right. So we've laid some groundwork, we've 158 00:07:10.439 --> 00:07:12.879 defined some key terms, we've looked at the evolution of 159 00:07:12.920 --> 00:07:16.160 security and Java. In part two of our deep dive, 160 00:07:16.199 --> 00:07:18.839 we're going to start really digging into the specifics of 161 00:07:18.920 --> 00:07:21.319 Jakarta authentication and Jakarta authorization. 162 00:07:21.560 --> 00:07:26.279 Great, can't wait, Stay tuned. Now, let's dive into Jakarta authentication, 163 00:07:26.639 --> 00:07:30.600 which is all about verifying those identities acting as the 164 00:07:30.639 --> 00:07:33.680 gatekeeper for our applications. Right, and we'll focus here on 165 00:07:33.759 --> 00:07:37.639 the servelet container profile, a key piece for web applications. 166 00:07:37.759 --> 00:07:40.680 So, how does Jakarta authentication work with those you know, 167 00:07:40.720 --> 00:07:44.519 those old workhorses, those servelet containers like Tomcat and JBoss. 168 00:07:44.680 --> 00:07:49.920 It integrates seamlessly with them, leveraging the container's existing security 169 00:07:49.959 --> 00:07:53.720 mechanisms to provide that robust authentication framework. 170 00:07:53.839 --> 00:07:57.319 Right. So it's working with the container, not against it, exactly. Okay, 171 00:07:57.319 --> 00:08:01.759 So walk us through how this authentication process actually unfolds. Sure, 172 00:08:01.839 --> 00:08:03.000 what are the steps involved? 173 00:08:03.040 --> 00:08:06.439 So imagine a user is trying to access a protected resource, right, 174 00:08:06.680 --> 00:08:09.279 their browser is going to send a request to the server. 175 00:08:09.800 --> 00:08:13.759 The server then checks if that resource requires authentication. 176 00:08:13.360 --> 00:08:14.040 And if it does. 177 00:08:14.160 --> 00:08:17.279 If it does, then the authentication mechanism kicks in. Okay, 178 00:08:17.319 --> 00:08:19.519 and this is where the server ofth module comes into play. 179 00:08:19.600 --> 00:08:22.560 Okay, So server off module this sounds like a pretty 180 00:08:22.600 --> 00:08:23.959 important piece of the puzzle. 181 00:08:24.040 --> 00:08:25.439 It is. Yeah, what role does it. 182 00:08:25.439 --> 00:08:27.000 Play in this whole process? 183 00:08:27.240 --> 00:08:29.759 The server off module is really at the heart of 184 00:08:29.839 --> 00:08:30.720 JA card authentication. 185 00:08:30.839 --> 00:08:31.160 Okay. 186 00:08:31.480 --> 00:08:34.320 It's highly configurable. It acts as a plug in point 187 00:08:34.399 --> 00:08:36.639 for custom authentication logic, so it's. 188 00:08:36.519 --> 00:08:39.720 Like a specialist security guard you can train to follow 189 00:08:39.799 --> 00:08:43.120 specific rules for your application exactly. So the server off 190 00:08:43.159 --> 00:08:46.600 module could interact with a database to validate user credentials 191 00:08:47.039 --> 00:08:50.039 or even connect to some external identity provider exactly. 192 00:08:50.080 --> 00:08:53.279 And it can use various callbacks to gather information from 193 00:08:53.639 --> 00:08:56.840 the user the user name and password, and then validate 194 00:08:56.919 --> 00:08:59.519 those credentials against an identity store. 195 00:08:59.600 --> 00:09:03.039 Okay, so we've authenticated our user right now, what how 196 00:09:03.039 --> 00:09:06.519 does Jakarta authorization step in to figure out what they 197 00:09:06.639 --> 00:09:08.159 can do what they can access. 198 00:09:08.519 --> 00:09:13.000 So, Jakarta authorization focuses on fine grained access control. It 199 00:09:13.039 --> 00:09:16.120 takes the security constraints that are defined in your web 200 00:09:16.159 --> 00:09:20.639 dot XML or through annotations and translates those into concrete 201 00:09:20.759 --> 00:09:22.879 permissions that can be checked at run time. 202 00:09:23.120 --> 00:09:25.279 So it's kind of like enforcing those rules about who 203 00:09:25.360 --> 00:09:28.200 can access what within the application precisely. 204 00:09:28.320 --> 00:09:32.039 Okay, Like if you have an admin dashboard that should 205 00:09:32.200 --> 00:09:36.480 only be accessible to users with the admin role, Jakarta 206 00:09:36.519 --> 00:09:38.159 authorization would enforce. 207 00:09:37.919 --> 00:09:40.360 That rule, gotcha. So it's making sure that only the 208 00:09:40.440 --> 00:09:43.759 right people get to see that admin dashboard exactly. Okay. 209 00:09:44.000 --> 00:09:47.960 That's pretty powerful, that ability to kind of control access 210 00:09:48.000 --> 00:09:48.799 at that level. 211 00:09:48.879 --> 00:09:49.200 It is. 212 00:09:49.840 --> 00:09:53.759 Now, what about those situations that require more complex rules, 213 00:09:54.279 --> 00:09:57.679 more than just those simple role based checks. Can Jakarta 214 00:09:57.720 --> 00:09:59.840 authorization handle that kind of nuance? 215 00:10:00.080 --> 00:10:03.720 It can? Yeah, Okay, you can create custom authorization modules 216 00:10:03.720 --> 00:10:06.480 to implement more intricate authorization logic. 217 00:10:06.600 --> 00:10:10.440 So for those really edge cases. Exactly, you've got that flexibility. Yeah, okay, 218 00:10:10.480 --> 00:10:12.600 good to know. Now, let's shift gears a little bit 219 00:10:12.600 --> 00:10:15.159 and top of Jakarta security and how it aims to 220 00:10:15.200 --> 00:10:18.799 make life a little easier for developers. Yeah, I understand. 221 00:10:18.919 --> 00:10:22.519 It provides this kind of higher level API that sits 222 00:10:22.559 --> 00:10:26.320 on top of Jakarta authentication and Jakarta authorization. 223 00:10:26.679 --> 00:10:28.000 It does the thinking there. 224 00:10:28.120 --> 00:10:32.120 It just streamlines the whole process of implementing those common 225 00:10:32.159 --> 00:10:34.799 security tasks in web applications. 226 00:10:34.919 --> 00:10:35.240 Okay. 227 00:10:35.519 --> 00:10:37.600 You can think of it as this pre built security 228 00:10:37.639 --> 00:10:40.360 system with all the essential features already in place, so. 229 00:10:40.360 --> 00:10:42.360 You don't have to reinvent the wheel every time you 230 00:10:42.399 --> 00:10:46.279 build a new application. Exactly, You've got the toolbox already there, right. Okay. 231 00:10:46.480 --> 00:10:49.000 So one of the key interfaces I understand in Jakarta 232 00:10:49.080 --> 00:10:53.200 security is the HTT authentication mechanisms. Yeah, does that do? 233 00:10:53.399 --> 00:10:56.639 So that's what enables you to implement the different authentication 234 00:10:56.759 --> 00:11:01.360 method like basic authentication, form based authent okay, or even 235 00:11:01.360 --> 00:11:02.679 those custom solutions. 236 00:11:02.960 --> 00:11:04.480 You know, it's funny, We've been talking about a lot 237 00:11:04.480 --> 00:11:06.240 of this kind of technical stuff and I just thought, 238 00:11:06.639 --> 00:11:08.799 you know, I'm curious, have you ever run into one 239 00:11:08.840 --> 00:11:11.600 of those capture things? Online where they ask you to 240 00:11:11.799 --> 00:11:14.960 identify the fire hydrants or the crosswalks. 241 00:11:15.039 --> 00:11:18.679 Oh yeah, those CAPTCHAs, Yeah, exactly right, all the time. 242 00:11:18.759 --> 00:11:20.799 It seems like they're everywhere these days. Yeah, what do you, 243 00:11:20.879 --> 00:11:21.960 I mean, what do you think of those? 244 00:11:22.159 --> 00:11:25.840 I think they can be effective in preventing automated attacks, 245 00:11:26.440 --> 00:11:28.639 but they're also kind of annoying for users. 246 00:11:29.039 --> 00:11:32.759 Yeah they are so I'm a human, I swear. Okay, 247 00:11:32.879 --> 00:11:35.559 back to Jakarta's security. We were talking about the HTT 248 00:11:35.720 --> 00:11:40.200 authentication mechanism, right, and how that helps developers implement those 249 00:11:40.279 --> 00:11:41.720 different authentication methods. 250 00:11:41.879 --> 00:11:44.120 Yeah, it provides a consistent way to plug in those 251 00:11:44.120 --> 00:11:46.840 different mechanisms and handle the authentication flow. 252 00:11:47.279 --> 00:11:49.879 Now, what about those remember me features we see on 253 00:11:49.919 --> 00:11:53.000 websites all the time. Oh yeah, how does Jakarta security 254 00:11:53.039 --> 00:11:55.159 support that kind of functionality? 255 00:11:55.240 --> 00:11:59.919 So Jakarta Security allows for persistent authentication, which is a 256 00:12:00.080 --> 00:12:03.000 essentially the mechanism behind those remember me features. 257 00:12:03.120 --> 00:12:03.440 Okay. 258 00:12:03.480 --> 00:12:06.200 It enables users to stay logged in for an extended 259 00:12:06.200 --> 00:12:09.480 period without having to repeatedly enter their credentials. 260 00:12:09.600 --> 00:12:11.679 Right, So it's convenient for the user, but it's also 261 00:12:12.000 --> 00:12:13.799 you know, there's some security implications there. 262 00:12:13.759 --> 00:12:16.320 Right, Absolutely, you have to be very careful about how 263 00:12:16.360 --> 00:12:18.600 you implement that remember me functionality. 264 00:12:18.919 --> 00:12:21.759 What are some best practices there? What should developers keep 265 00:12:21.759 --> 00:12:22.159 in mind? 266 00:12:22.919 --> 00:12:26.039 So you want to make sure you're using secure token 267 00:12:26.080 --> 00:12:31.960 based approaches, okay, You want to implement robust token expiration mechanisms, right. 268 00:12:31.840 --> 00:12:33.960 So the tokens don't last forever exactly. 269 00:12:34.080 --> 00:12:37.000 Yeah, and you want to educate your users about the 270 00:12:37.039 --> 00:12:38.960 potential risks, especially. 271 00:12:38.639 --> 00:12:40.600 About staying logged in on shared devices. 272 00:12:40.759 --> 00:12:42.159 Yeah, exactly, good point. 273 00:12:42.159 --> 00:12:45.039 Good point. Now, I understand that your Karda's security also 274 00:12:45.080 --> 00:12:49.080 integrates nicely with CDI context and dependency injection. 275 00:12:49.200 --> 00:12:49.639 It does. 276 00:12:49.799 --> 00:12:52.559 How does CDI help to kind of streamline the whole 277 00:12:52.600 --> 00:12:55.279 management of these security related components. 278 00:12:55.519 --> 00:12:58.240 So CDI is kind of like the nervous system of 279 00:12:58.279 --> 00:13:03.240 your application. It connect the different parts and manages the dependencies. 280 00:13:03.320 --> 00:13:07.399 And with Jakarta security, that means easier management of those 281 00:13:07.440 --> 00:13:09.799 security related beans and services. 282 00:13:10.200 --> 00:13:12.120 Okay, So CDI is kind of taking care of all 283 00:13:12.159 --> 00:13:13.720 the wiring behind the scenes, so you don't have to 284 00:13:13.720 --> 00:13:14.639 worry about it as much. 285 00:13:14.799 --> 00:13:15.440 Exactly. 286 00:13:15.600 --> 00:13:17.679 That's nice, less for the developer to worry about it. 287 00:13:17.759 --> 00:13:21.720 Right now, we've been talking about user initiated authentication, like 288 00:13:21.759 --> 00:13:23.759 when you click on a log in button. But what 289 00:13:23.840 --> 00:13:27.879 about those situations where it's the container that initiates the authentication, 290 00:13:28.159 --> 00:13:29.320 maybe to access. 291 00:13:29.000 --> 00:13:31.480 A particular resource, right, Yeah, does. 292 00:13:31.399 --> 00:13:33.519 Jakarta Security handle that as well? 293 00:13:33.559 --> 00:13:36.000 It does. It handles both scenarios gracefully. 294 00:13:36.120 --> 00:13:39.360 Okay, So whether the user wants to log in or 295 00:13:39.440 --> 00:13:42.320 is first to log in, Jakarta Security's got it covered. 296 00:13:42.519 --> 00:13:42.759 Yeah. 297 00:13:42.759 --> 00:13:46.960 It provides that comprehensive framework for handling those authentication flows 298 00:13:46.960 --> 00:13:48.039 in web applications. 299 00:13:48.399 --> 00:13:52.000 That's great. Now, we've been focusing a lot on web applications, right, 300 00:13:52.120 --> 00:13:55.399 but what about Jakarta Faces. Okay, how does Jakarta Security 301 00:13:55.399 --> 00:13:56.639 apply in that context? 302 00:13:56.799 --> 00:14:00.639 So Jakarta Security is equally relevant in Jakarta Face's applications. 303 00:14:00.679 --> 00:14:04.399 It allows you to control access to specific UI components 304 00:14:04.480 --> 00:14:07.399 or actions based on user roles and permissions. 305 00:14:07.600 --> 00:14:10.279 So you can use those annotations like at roles allowed 306 00:14:10.360 --> 00:14:13.519 and at servelet security to kind of fine tune access 307 00:14:13.559 --> 00:14:17.559 control even at the level of individual UI elements precisely, 308 00:14:17.720 --> 00:14:20.440 so you could have a button that only certain users. 309 00:14:20.120 --> 00:14:21.639 Can see, exactly, or a. 310 00:14:21.639 --> 00:14:23.960 Form that only certain users can submit. 311 00:14:24.159 --> 00:14:27.320 Yeah, it's very powerful in terms of protecting sensitive information 312 00:14:27.399 --> 00:14:28.039 and actions. 313 00:14:28.159 --> 00:14:31.559 Really gives you that granular control. Yeah, okay, so we've 314 00:14:31.600 --> 00:14:36.200 got this comprehensive solution for managing security in both servelet 315 00:14:36.240 --> 00:14:38.320 based and Jakarta Faces applications. 316 00:14:38.519 --> 00:14:38.960 We do. 317 00:14:39.240 --> 00:14:41.759 It's quite a toolkit, it is. Now it's important to 318 00:14:41.759 --> 00:14:45.159 remember that security is not a one time thing. This 319 00:14:45.240 --> 00:14:46.519 is an ongoing process. 320 00:14:46.639 --> 00:14:46.840 It is. 321 00:14:46.919 --> 00:14:48.519 Yeah, to the vigilant, you have to stay. 322 00:14:48.440 --> 00:14:49.480 Up to date exactly. 323 00:14:49.600 --> 00:14:52.360 Staying up to date with the latest best practices and 324 00:14:52.480 --> 00:14:57.360 security updates is absolutely cruefl for building and maintaining secure applications. 325 00:14:57.600 --> 00:15:00.480 It's a never ending battle. It is now explored a 326 00:15:00.480 --> 00:15:03.159 lot within the realm of Jakarta E. But let's take 327 00:15:03.200 --> 00:15:06.200 a step back for a moment and look at the foundations. Sure, 328 00:15:06.240 --> 00:15:09.200 the java SE elements that underpin all of this. All right, 329 00:15:09.279 --> 00:15:11.399 It's kind of like you have to understand the foundation 330 00:15:11.480 --> 00:15:14.240 of a skyscraper, right, Yeah, you can't just appreciate the 331 00:15:14.240 --> 00:15:18.519 fancy design on those top floors without knowing what's holding it. 332 00:15:18.519 --> 00:15:19.320 All up exactly. 333 00:15:19.399 --> 00:15:23.320 Jakarta E security wouldn't exist without those core elements from 334 00:15:23.399 --> 00:15:26.720 java SE, right, and understanding them gives you a much 335 00:15:26.759 --> 00:15:30.200 deeper appreciation for how security works at all levels. 336 00:15:30.600 --> 00:15:34.240 Okay. So let's start with JA, the Java Authentication and 337 00:15:34.320 --> 00:15:37.720 Authorization Service. Okay, we talked about it a little bit before, 338 00:15:37.720 --> 00:15:40.080 but now let's look at it from that Java SE perspective. 339 00:15:40.120 --> 00:15:43.039 All right. Yeah, JA is considered like the granddaddy of 340 00:15:43.120 --> 00:15:46.399 Java security, Okay, and it's still very relevant today. 341 00:15:46.480 --> 00:15:46.919 Oh wow. 342 00:15:47.120 --> 00:15:52.519 It provides this framework for implementing custom authentication logic even 343 00:15:52.600 --> 00:15:53.720 outside of Jakarta. 344 00:15:53.799 --> 00:15:54.039 Ee. 345 00:15:54.240 --> 00:15:57.120 So you mentioned these custom logan modules earlier. What exactly 346 00:15:57.200 --> 00:16:00.519 are those and how do they fit into JMEA module? 347 00:16:00.519 --> 00:16:03.840 You can think of it as like a specialized authentication routine. 348 00:16:04.200 --> 00:16:06.960 So let's say you need to authenticate users against a 349 00:16:07.080 --> 00:16:10.519 legacy system that doesn't follow standard protocols, right, you could 350 00:16:10.559 --> 00:16:14.639 write a custom login module to handle that specific authentication process. 351 00:16:14.840 --> 00:16:17.279 So it gives you that flexibility to adapt to unique 352 00:16:17.320 --> 00:16:21.879 situations exactly. Okay, that's really valuable. Now, what about cryptography. 353 00:16:22.200 --> 00:16:25.720 How does Java SE handle the need to protect sensitive 354 00:16:25.799 --> 00:16:29.440 data both when it's stored and when it's transmitted over networks. 355 00:16:29.799 --> 00:16:32.759 That's where JCE comes in, the Java Cryptography Extension. 356 00:16:32.840 --> 00:16:33.080 Okay. 357 00:16:33.159 --> 00:16:37.240 JC it's basically your toolbox for all things cryptography, and Java. 358 00:16:37.360 --> 00:16:41.039 So provides the tools that developers need to encrypt data, 359 00:16:41.200 --> 00:16:44.360 generate keys, implement different algorithms, all that stuff. 360 00:16:44.519 --> 00:16:48.559 Exactly. JCE is a very powerful framework that supports a 361 00:16:48.639 --> 00:16:50.759 wide range of cryptographic operations. 362 00:16:50.919 --> 00:16:51.240 Wow. 363 00:16:51.399 --> 00:16:54.679 And it also allows developers to plug in different cryptographic 364 00:16:54.720 --> 00:16:57.919 implementations through what are called JCE providers. 365 00:16:58.000 --> 00:16:59.720 Okay, JCE providers, what are those? 366 00:17:00.039 --> 00:17:02.639 So let's say you need to use a specific encryption 367 00:17:02.759 --> 00:17:06.640 algorithm that's not provided by the default providers in the JDK. 368 00:17:07.000 --> 00:17:10.519 You can then incorporate an external provider like bouncy Castle, 369 00:17:10.759 --> 00:17:12.880 which offers a wider range of algorithms. 370 00:17:13.000 --> 00:17:15.039 So it gives you that flexibility to choose the best 371 00:17:15.039 --> 00:17:17.680 tool for the job exactly. Okay. You know, we can't 372 00:17:17.720 --> 00:17:22.319 really talk about security without mentioning TLS Transport layer security, right. 373 00:17:22.720 --> 00:17:26.319 It's what makes secure communication over the Internet possible. 374 00:17:25.960 --> 00:17:29.200 Absolutely essential for protecting data in transit. 375 00:17:29.440 --> 00:17:32.799 Right. So that's what ensures that your credit card information 376 00:17:32.920 --> 00:17:36.000 is safe when you're shopping online, your confidential messages are 377 00:17:36.000 --> 00:17:39.119 protected exactly. Now. I think most people are familiar with 378 00:17:39.119 --> 00:17:42.960 that little padlock icon in their browser that indicates HTTPS. 379 00:17:43.440 --> 00:17:45.960 But what's actually happening behind the scenes to make that 380 00:17:45.960 --> 00:17:48.359 secure connection possible. 381 00:17:47.960 --> 00:17:52.759 So TLS uses a combination of public key, cryptography and 382 00:17:52.880 --> 00:17:57.640 digital certificates to establish that secure channel between your browser 383 00:17:57.720 --> 00:17:58.480 and the web server. 384 00:17:58.680 --> 00:17:59.000 Okay. 385 00:17:59.039 --> 00:18:01.279 It's a process called an and shake where the two 386 00:18:01.400 --> 00:18:05.720 parties basically exchange cryptographic keys and verify each other's identities. 387 00:18:05.839 --> 00:18:08.039 So it's making sure you're talking to the right website 388 00:18:08.079 --> 00:18:09.880 and that nobody's eavesdropping in the middle. 389 00:18:10.079 --> 00:18:10.640 Exactly. 390 00:18:10.720 --> 00:18:14.200 Okay, that makes sense. What about different versions of TLS, 391 00:18:14.200 --> 00:18:15.720 I know there have been several over the years. 392 00:18:15.880 --> 00:18:17.920 Yeah, and it's very important to use the latest and 393 00:18:17.960 --> 00:18:21.279 most secure version, which is currently TL's one point three. 394 00:18:21.400 --> 00:18:23.240 Okay, TLS one point three, got it. 395 00:18:23.240 --> 00:18:26.839 It has significant improvements in both speed and security compared 396 00:18:26.880 --> 00:18:28.000 to older versions. 397 00:18:28.519 --> 00:18:32.319 Good to know. Now we've covered those foundational elements in Java, 398 00:18:32.559 --> 00:18:38.160 se JAS, JCE, TLS. Yeah, but when we talk about 399 00:18:38.559 --> 00:18:43.240 managing identities on a larger scale across multiple applications, you know, 400 00:18:43.440 --> 00:18:47.200 entire systems, we need more sophisticated tools, right, and that's 401 00:18:47.240 --> 00:18:49.039