Elementor #31920

Security is a common challenge for everyone. Standard and robust patterns exist and are known in traditional infrastructure. However, the serverless change the game and imply a false feeling of losing control, especially in the security part. This session is focused on all the ways to secure the communication to and from serverless compute products on Google Cloud. The OAuth2 token generation and the difference of usage between access token and identity token, IAM service and the service/user accounts, VPC access and private networks access, load balancers, ingress and egress control will no longer have mysteries for you at the end of the session!

Guillaume Blaquiere
Group Data Architect at Carrefour, Google Developer Expert - Cloud

In this session you will dive into system-to-sytem authentication and the issues and challenges this brings in many organizations, both technical and non-technical. Then we will talk about Azure Managed Identity, what it is and how this can help you solve all those issues, reduce complexity and increase the ease of working.

Henry Been
Independent DevOps & Azure Architect | Microsoft MVP | Author

We think too often about 'secure code' being only about our code. Dependencies are the most common vehicle for attacks in enterprise systems, however it doesn't end there...there is so much more that we consume, and we usually just trust without questions! Let's take a look at how we can secure our software supply chain, and prevent what could easily turn into disaster.

Matteo Emili
Head of Software Engineering at Avanade UK and Ireland

Security in Jakarta EE has long been under used and under specified. The existing set of specifications ranged from overly complex to non-existent. The result was almost nobody used standards for security. Java EE 8 changed that with JSR 375, the Java EE Security API. Its evolution Jakarta Security facilitates portable application security that integrates with container security. Allowing an application to provide authentication mechanisms like OAuth or OpenID Connect and that mechanism is treated just like built-in container mechanisms like FORM. Existing security mechanisms like the container-based access to a URL defined by web.xml constraints, and things like @RolesAllowed and HttpServletRequest.isUserInRole automatically work as expected. It depends on CDI, and the lower level SPIs Jakarta Authentication and Jakarta Authorization. Jakarta Authorization defines an SPI for authorization modules, which are permission repositories for subject based security by checking if a subject has given permissions, and algorithms to transform security constraints for containers including Jakarta Servlets or Enterprise Beans into these permissions. Jakarta Authentication defines an SPI for authentication that interacts with a caller and a container’s environment to obtain the caller’s credentials, validate them and pass an authenticated identity (e.g. name, groups,...) to the container. This hands-on session is intended to get attendees up to speed with the current state of Jakarta Security specs, demonstrate Compatible Implementation like Eclipse Soteria, Eleos and Exousia as well as others including Glassfish or Tomcat. We will ask the audience for their opinion and thoughts what else they would like to see in the Jakarta EE Security specs with Jakarta EE 11 and beyond.

Werner Keil
Java, Jakarta EE und Microservice Experte im Gesundheitswesen KKH Kaufmännische Krankenkasse