search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 599 forks source link

Implement MicroProfile JWT Bridge spec #25918

Open ayoho opened 1 year ago

ayoho commented 1 year ago

Description

Add functionality in Open Liberty to support the MP JWT Bridge specification: https://github.com/eclipse/microprofile-jwt-bridge:

This specification enables mapping MicroProfile JWT tokens to Jakarta EE container APIs not included in the MicroProfile umbrella and provides a place where Jakarta EE specifications, such as Jakarta Security, can build requirements and seamless integrations with MicroProfile JWT.

The crux of the MP JWT Bridge specification is the creation of a new @JwtAuthenticationMechanismDefinition annotation used to define a JWT authentication mechanism for verifying JWT bearer tokens which are sent with HTTP Authorization or other headers.

An example of the auth mechanism's usage is shown here:

@JwtAuthenticationMechanismDefinition(
    jwtClaimsDefinition = @JwtClaimsDefinition(callerNameClaim = "upn", callerGroupsClaim = "groups"),
    publicKeyDefinition = @PublicKeyDefinition(key = "", location = "", algorithm = "RS256"),
    decryptionKeyDefinition = @PrivateKeyDefinition(location = "", algorithm = ""),
    jwtClaimsVerification = @JwtClaimsVerification(issuer = "", audiences = "", tokenAge = 0, tokenAgeExpression = "", clockSkew = 0, clockSkewExpression = ""),
    httpHeadersDefinition = @HttpHeadersDefinition(tokenHeader = "Authorization", cookieName = "Bearer"),
    jwksDefinition = @JwksDefinition(jwksConnectTimeout = 500, jwksConnectTimeoutExpression = "", jwksReadTimeout = 500, jwksReadTimeoutExpression = ""))
public class JwtSecuredServlet extends HttpServlet {

    @Inject jakarta.security.enterprise.SecurityContext securityContext;

    @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // example of getting JWT claims from Jakarta SecurityContext
        jakarta.security.enterprise.identitystore.openid.JwtClaims jwtClaims = securityContext.getPrincipalsByType(...);
    }
}

Documents

When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.

General Instructions

The process steps occur roughly in the order as presented. Process steps occasionally overlap.

Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").

Unless otherwise indicated, the tasks are the responsibility of the feature owner or a delegate of the feature owner.

If you need assistance, reach out to the OpenLiberty/release-architect.

Important: Labels are used to trigger particular steps and must be added as indicated.

Prioritization (Complete Before Development Starts)

The OpenLiberty/chief-architect and area leads are responsible for prioritizing the features and determining which features are being actively worked on.

Prioritization

Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID. Furthermore, each identified item places a blocking requirement on another team so it must be identified early in the process. The feature owner may check-off the item if they know it doesn't apply, but otherwise they should work with the focal point to determine what work, if any, will be necessary and make them aware of it.

Design Preliminaries

Design

No Design

FAT Documentation

A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the Design Approved or No Design Approved label, along with all other tasks outlined in the GA section.

Feature Development Begins

Legal and Translation

In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. All items below MUST be completed before beta & GA is requested.

Innovation (Complete 1 week before Beta & GA Feature Complete Date)

Legal (Complete before Beta & GA Feature Complete Date)

Translation (Complete by Beta & GA Feature Complete Date)

In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.

Beta Code

Beta Blog (Complete by beta eGA)

A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.

Feature Complete

Focal Point Approvals (Complete by Feature Complete Date)

These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.

All Features

Design Approved Features

Remove Beta Fencing (Complete by Feature Complete Date)

GA Blog (Complete by Friday after GM)

Post GM (Complete before GA)

Post GA

ayoho commented 9 months ago

I've added the pause_review label since Jakarta work will be taking precedence over the MP JWT Bridge spec implementation.