 understand the motivation for introducing Eletron. Then we're gonna jump right into what Eletron is and we'll go through its core concepts for both server side authentication and client side authentication. And then we'll go through a demo so you can see how to secure an application that's been deployed to WildFly using Eletron. So, historically, Java application server security has been provided by the Java Authentication and Authorization Service, also known as JAZ. Now, as its name suggests, JAZ is a set of Java APIs designed for authentication and authorization. Now JAZ implements the Plugable Authentication Module. And so since authentication is performed in a Plugable way, it allows for applications to remain independent of the underlying authentication technologies. So it was common for application servers to make use of JAZ login modules for username password verification. Now, in the early days of application servers, this solution was fine, but as finding ways to improve security became more important, this simple solution was no longer adequate and it actually became difficult to use effectively. So for JVOS application server seven, which is the predecessor of the WildFly application server, we really wanted to switch to more secure, to stronger authentication mechanisms. So specifically, we wanted to be able to use Sassel-based authentication for our native interface. Now, Sassel is a challenge response-based protocol. So the way it works is that the server issues a challenge to the client, the client responds to the challenge and the exchange continues until the server is happy and doesn't send any more challenges. Now, the main problem with switching to Sassel was that it was totally incompatible with JAZ. So we actually ended up with two security solutions, one based on JAZ for applications, one based on Sassel for management and we had integration between the two. Now, obviously having two different security solutions that solved the same authentication problem, but in two different ways, was not ideal and it became confusing for both users and developers. So this led to the creation of the Elitron project in order to provide a single unified security solution across the whole WildFly application server. So what is Elitron? Elitron is a set of Java APIs and SPIs for application server security. Now, in addition to providing a single unified security solution for WildFly, we also had a few other objectives when introducing Elitron. So in particular, we wanted to support stronger authentication mechanisms. So we wanted to move beyond the JAZ login modules. Next, we also wanted to centralize SSL configuration so that different parts of the application server that require SSL could make use of the same centralized configuration. Next, we wanted to be able to support identity switching and identity propagation. And finally, we wanted to be able to provide integration points to make it possible to create custom implementations that could extend Elitron functionality if necessary. So within WildFly, Elitron is used to secure applications that are deployed to the server and to secure management access to the server. It's important to keep in mind though that although Elitron was developed for WildFly, it's actually a standalone library that can theoretically be used in other Java server environments. Elitron covers the two main security areas, authentication and authorization. Now just as a reminder, authentication involves verifying someone is really who they say they are and authorization involves verifying that they're actually allowed to access a resource. So Elitron's APIs are based on a few core components. And so we're gonna go through these components now. The most important component is the security domain. So a security domain is a representation of a security policy and it's backed by one or more security realms and a set of resources that can perform transformations. A security realm provides access to an identity store. So it can encapsulate a database, an LDAP server, properties file, key store and so on. Now a security realm can be used to obtain attributes that are associated with an identity and to obtain or verify credentials that are associated with an identity. Now some of our security realm implementations also expose an API for modifications. So that means that it's possible to make updates to the underlying identity stores. So you could add users, remove them, update them and so on. Next we have a realm mapper. So a realm mapper is associated with a security domain and it's used in cases where the security domain is backed by multiple security realms. So a realm mapper takes the username that's been provided during authentication and it uses it to determine which security realm should be used in order to obtain the identity information for that user. So as an example here, you can see that this security domain is backed by three security realms. So when the authentication process starts and we see a username like aliceatredhat.com, this security domain needs to determine which of these security realms it's going to use in order to obtain the identity information for Alice. So it takes its realm mapper and it maps aliceatredhat.com to a security realm. Now in this example, it's been mapped to the LDAP server. So this will be the security realm that's used to obtain the identity information for Alice. Next we have a principal transformer. It can be used to map a name to another name. So in this example, it maps aliceatredhat.com to just Alice. This can be useful if the identity store has user names in a different format than what's being provided during authentication. So once authentication has succeeded, a security domain produces a security identity and that's the representation of the current user. Now resources that need to make authorization decisions can be associated with a security domain. Now that security domain can then be used to obtain the current identity and its roles and permissions can then be checked in order to make authorization decisions. Now a security identity's roles and permissions are determined using resources that are associated with the security domain. So in particular, a role decoder can be used to decode the current user's roles. So it takes the raw identity information that's been obtained from the security realm and it uses it to map its attributes to roles. So in this example, the role decoder determined that aliceatredhat.com has two roles, admin and employee. Next we have a role mapper. It can be used to apply a role modification to an identity. So it can be used for normalizing roles, adding or removing roles. In this example, it adds the prefix redhat to each role. Finally, we have the permission mapper. It can be used to assign a set of permissions to an identity. So in this example, the security identity for alice gets mapped to two permissions, the login permission and the run as principle permission. So, so far we've taken a look at the resources that back a security domain. Now one thing to note is that it's possible to configure a security domain to inflow a security identity from another security domain. So when an identity is inflowed, it retains its raw original identity, but it gets assigned a new set of roles and permissions using the new security domains, role decoders, role mappers and permission mappers. So you actually end up with a new security identity. Another important component is the authentication factory. So an authentication factory represents an authentication policy and it's a factory for the configured server side authentication mechanism. Now Elitron provides both HTTP mechanisms like digest, form, client cert and so on and sassel mechanism. So some examples are digest MD5, scram and GS2. So next, the SSL context is used to define all policy information related to SSL. Now, in addition to the usual configuration for an SSL context like key managers and trust managers, Elitron allows you to provide configuration for additional things like cipher suites and protocols. Elitron also provides secure credential stores and these are used for secure storage and use of credentials. Now the way they work is that they allow you to associate an alias with a credential. You can then reference that alias directly in the wild fly configuration file so you don't have to specify your credential directly. So as an example here you can see you'd specify something like credential reference and then you'd give the store name which is the name of the credential store that you want to use and then you'd specify which alias you'd like to use and that represents the credential that you want to reference. So, so far we've been talking about the Elitron components for server side authentication. Now Elitron also provides a set of Java APIs and SPIs for client side authentication. Now, when I say client side, I just mean the client side of the connection that's being established. It is also possible to use client side authentication in a server environment so when you're connecting from one server to another server. Now Elitron's client APIs allow remote clients to authenticate using Elitron. So we're now gonna go through the components for the Elitron authentication client. So the first component is the authentication configuration. It contains all of the information that will be used when attempting to authenticate. So this includes things like principles, credentials and the authentication mechanisms that should be used. Now you can also use credential stores here so you don't have to specify the credentials directly in the authentication configuration. Next, we have SSL context configuration. So this is just like the SSL context configuration on the server side so you can specify things like key managers, trust managers, cipher suites and protocols. Now finally, we have the authentication context. It consists of an ordered collection of match rules that are used to determine which authentication configuration and which SSL context configuration should be used when attempting to authenticate. So for example, you could have one authentication configuration that gets used when connecting to one server and a different authentication configuration that gets used when connecting to a different server. Now it's possible for Elitron client side authentication to be configured using an XML configuration file. Now this file can be specified using the wildfly config URL system property. And if that property hasn't been specified then Elitron will look in the class loader's root directory and it's meta-inf directory for this file. So this is an example of a very simple client side XML configuration file. It has one authentication configuration specified and no SSL context configuration. So if we look at the top, we can see that there's one match rule, okay? And it says that when we connect to server1.com the default config authentication configuration should be used. And the default config authentication configuration says that we should be using alice at redhat.com as the username, secret as the password, and we're gonna use the digest MD5 SASL authentication mechanism. So this information gets used when we're attempting to authenticate. Now it's also possible to specify client side authentication programmatically. So this example is just like the previous example. It has one match rule that says when we connect to server1.com this is the authentication configuration that should be used. And again, we're saying that we want to use alice at redhat.com as our username, secret as the password. And we're also specifying that we wanna use the digest MD5 SASL authentication mechanism. Next, we can specify the code that we want to run under this authentication context. So as this code is running, when it attempts to authenticate this is the information that's gonna be used to do that. So those were the elitron components for client side authentication. Now, while the majority of wildfly users are probably going to use the functionality that's already provided by elitron, it is possible to use elitron's APIs and SPIs to create custom implementations that extend elitron functionality. So for example, you can implement custom authentication mechanisms, SSL contacts, credential stores and password implementations. And so these can be registered using Java security providers or Java service loader discovery. Now, out of the box, wildfly still uses its legacy security subsystem by default. However, elitron is already installed and it's ready to be used. Now, the reason for this is that we want to minimize disruption as users migrate to elitron. So in the future, wildfly's legacy security subsystem will be completely removed and elitron will become the default. So now we're going to take a look at an example application that I've deployed to wildfly. It's a simple inventory application for a store called wildfly widgets. It has two servlets that invoke an EJB. Both servlets have a constraint specified that says that only users with employee role should be allowed to access these servlets. Now, the first servlet is the inventory servlet and it allows you to view the list of products that are currently in stock. Now, it invokes an unsecured EJB method called getProducts and that retrieves the products that are in stock. Now, our EJB is called the products bean and you can see that it's associated with a security domain called other. Our next servlet is called the add servlet. It allows you to add a product to the list of products that are in stock. Now, it invokes an EJB method called addProduct that requires admin role. So as you can see here, it has this roles allowed annotation which specifies that you must have admin role to invoke this method. So we're going to create an elitron file system security realm with two users, Alice and Bob. Alice is going to have both admin role and employee role and Bob is only going to have the employee role. So we can create this file system security realm using wildfly CLI commands. So in particular, we can use the file system realm add operation to create a new security realm called example realm. The path attribute here specifies the location on your file system where you want this new elitron security realm to be stored. We can also use CLI commands to add our users. So we can use the add identity operation to add the Alice identity to our file system realm called example realm. We can then use the set password operation to set Alice's password to Alice123 plus. Now notice I'm just specifying a clear password here but it is possible to specify many different password types. So as an example, you could specify like a salted digest password here if you wanted to. Next, we can use the add identity operation, add identity attribute operation in order to assign Alice two roles and we're assigning her employee and admin. Okay, and now we can repeat the process for Bob but we're only going to assign him employee role. So now that we have created this file system security realm, we need to add it to an elitron security domain. Now the default wild fly configuration file already has an elitron security domain called application domain. And so we're gonna take this elitron file system security realm that we just created and we're going to add it to the list of security realms that back this existing domain. And so we can use the list add operation to add this example realm to the existing list of realms. And then we can set the default realm that's used by this security domain to the realm that we just created. So to indicate that security for our servlets and our EJB should be handled by elitron instead of by the legacy security subsystem, we need to add some configuration to the undertow and EJB subsystems and we do this in order to map the security domain name that's been referenced in our application to the elitron security domain that we want to use. So if you recall our application referenced the other security domain and there it was specified using a security domain annotation but it could also have been defined using a descriptor file. So we take that security domain name that's been specified in our deployment and we add an application security domain mapping in our undertow subsystem to map that name other to application domain. And so again application domain is the elitron security domain that we want to use. And then we repeat the process in the EJB subsystem. We add another application security domain mapping. Now there's just one more configuration change that we need to make in order to secure our application using elitron. And so that's to update the HTTP promoting connector to reference the sassel authentication factory that is backed by our elitron security domain. Now the default wildfly configuration file already defines a sassel authentication factory that's backed by our application domain. So we're just going to update our HTTP promoting connector so that it references that existing sassel authentication factory, okay? And it's called application sassel authentication. And finally we can undefine the security realm attribute that's defined for the HTTP promoting connector. And we can do that because that attribute is a legacy attribute. And so it's not going to be used when using elitron. So now once the reload operation is executed in the wildfly CLI, everything will have been set up so that now our application will be secured using elitron instead of using our legacy security subsystem. So now let's take a look at our application. So again, you can see that there's two buttons, view inventory and add product. So let's try to click on view inventory and let's log in as Bob. Now remember Bob only has employee role. Okay, so we're going to log in. And so we can see that we're able to successfully view the list of products that are currently in stock. And again, that only requires employee role to be able to access this page. And so we're able to do this successfully. If we go back and now we try to add a product, okay? So let's say we're adding a football, let's say its price is 17.99 and that we have 40 in stock. Now this time, if we click submit here, we get a failure message that says that only an admin can add a product. And so that's expected because Bob is not an admin. So now if we go back and we try to view inventory again, but this time is Alice. Okay, so we can see that again, we're able to successfully view the list of products that are currently in stock since Alice has employee role. Now if we go back and we attempt to add a product again, so let's use the same information. So let's say football, 17.99, 40 in stock. And we click submit. This time we get a success message that says that the product was successfully added and that's because Alice is an admin. And now if we go back, we'll see that the football now appears in the list of inventory. So today we've talked all about Elitron, which is a set of Java APIs and SPIs for application server security. We went through an example of how to secure an application that's been deployed to WildFly using Elitron. And the important thing to keep in mind is that Elitron is a standalone library so it can theoretically be used in other Java server environments. Thanks. Any questions? Okay. So the question was if we wanted to use Elitron in Tomcat server, what would we have to do? So it would be, you'd have to take a look at how security is currently configured on the server side and then you would plug in these different Elitron components. So you'd need to have a way to configure things like authentication factories, security domains, and security realms, okay? And as long as you have a way to configure that, then the server can make use of that. And then on the client side, it's just a matter of adding like an Elitron dependency and you can make use of the remote client APIs. Now we did actually do some prototype work with looking at how we'd integrate Elitron with Jetty. So we do have a proof of concept for that. And I think as part of our future work, we'll be looking to see how we can integrate with other Java servers as well. It is, it's on GitHub. I can point you to the, oh, okay. So I'm not, like I don't know too much about the spring security framework. So I'm not 100% sure how to answer that question, but does it have similar concepts like security identities and security domains or, okay. So one advantage of Elitron is that you can define everything in one place. So in what spring it might be that you have to define it in multiple different configuration files. And maybe you're specifying the same thing multiple times in different places. Things like that. In that sense, Elitron is better because you can define everything just in the Elitron subsystem within Wildfly. And that's your one spot for security for all the various subsistence. We can support like two-way SSL and stuff. So, I mean, I don't think spoofing would be a concern there, but I guess it's something that should be looked into further. Oh no, that's okay, that's better. All right, cool. Yeah, I guess a second. Oh, I'll plug in here. Sorry? It starts at 210, right? Yep, I think so. 210? Okay. Let's swap this out. Do you guys know how to set this back up?