Reorganize and cleanup auth stdlib

[ayomawdb]

Purpose

Resolve following auth stdlib related improvements and feature additions.

• Move JWT token creation related functions out of internal pkg
  • Resolve Move JWT token creation related functions out of internal pkg #9792
• JWT token propagation configs should be moved to client-endpoint Auth config section
  • Resolve JWT token propagation configs should be moved to client-endpoint Auth config section #10478
• Improvements to authentication & authorization API
  • Resolve Improvements to authentication & authorization API  #10471
• Separate inbound and outbound authentication configuration
  • Resolve Separate inbound and outbound authentication configuration #11321
• [JWT] Require predefined JWT Header algorithms
  • Resolve [JWT] Require predefined JWT Header algorithms #11528
• [Auth] Authorization failure when engaging empty scopes for HTTP service config
  • Resolve [Auth] Authorization failure when engaging empty scopes for HTTP service config #13325
• Move JWT token creation related functions out of internal pkg
  • Resolve Move JWT token creation related functions out of internal pkg #9792

In addition, this PR reorganize the client and server endpoint auth configurations, to make it easier to understand. Previously, configuration for all the authentication mechanisms were put in record, which confused uses on which configurations to use for each authentication mechanism. Now the client auth configuration has been separated as follows:

# AuthConfig record can be used to configure the authentication mechanism used by the HTTP endpoint.
#
# + scheme - Authentication scheme
# + basicAuthConfig - Configuration for BasicAuth scheme
# + oAuth2AuthConfig - Configuration for OAuth2 scheme
# + jwtAuthConfig - Configuration for JWT scheme. If inbound authentication is JWT, sends the same JWT with client
#                   invocation, unless reissuing is configured using InferredJwtIssuerConfig.
public type AuthConfig record {
    OutboundAuthScheme scheme;
    BasicAuthConfig basicAuthConfig?;
    OAuth2AuthConfig oAuth2AuthConfig?;
    JwtAuthConfig jwtAuthConfig?;
    !...;
};

In addition, improve the crypto and encoding stdlib to provide operations that are required for internal workings of auth stdlib. This limits to:

• Adding RSA signature verification support
• Adding Base64Url encoding and decoding support

Update 1

AuthConfig was changed to use union for configuration.

# AuthConfig record can be used to configure the authentication mechanism used by the HTTP endpoint.
#
# + scheme - Authentication scheme
# + config - Configuration related to the selected authenticator.
public type AuthConfig record {
    OutboundAuthScheme scheme;
    BasicAuthConfig|OAuth2AuthConfig|JwtAuthConfig config?;
    !...;
};

[davebaol]

In addition, this PR reorganize the client and server endpoint auth configurations, to make it easier to understand. Previously, configuration for all the authentication mechanisms were put in record, which confused uses on which configurations to use for each authentication mechanism. Now the client auth configuration has been separated as follows:

# AuthConfig record can be used to configure the authentication mechanism used by the HTTP endpoint.
#
# + scheme - Authentication scheme
# + basicAuthConfig - Configuration for BasicAuth scheme
# + oAuth2AuthConfig - Configuration for OAuth2 scheme
# + jwtAuthConfig - Configuration for JWT scheme. If inbound authentication is JWT, sends the same JWT with client
#                   invocation, unless reissuing is configured using InferredJwtIssuerConfig.
public type AuthConfig record {
    OutboundAuthScheme scheme;
    BasicAuthConfig basicAuthConfig?;
    OAuth2AuthConfig oAuth2AuthConfig?;
    JwtAuthConfig jwtAuthConfig?;
    !...;
};

I see your point and this is certainly easier to understand, but I would have expected something like that

public type AuthConfig record {
    OutboundAuthScheme scheme;
    BasicAuthConfig|OAuth2AuthConfig|JwtAuthConfig config;
    !...;
};

Why do you prefer 3 optional fields in place of a union?

[ayomawdb]

@davebaol Thank you for the feedback. Yes you have a valid point here and I do not have any strong point to defend using separate optional config records.

There were some implementation complications related to record ambiguity that prevented using an union initially. We are working on reorganizing and improving OAuth2 related logic, targeting March end. Initial idea was to do this with OAuth2 related changes.

However, I agreed with you that will change will look very neat and clean with a single union for configuration. I had some time to further look at record ambiguity problem, and I have now used union for configuration, as you have suggested. Updated PR description accordingly.

@davebaol thanks again for the valuable input!

[codecov-io]

Codecov Report

Merging #13808 into master will decrease coverage by 0.61%.
The diff coverage is 74.14%.

@@             Coverage Diff              @@
##             master   #13808      +/-   ##
============================================
- Coverage     65.14%   64.52%   -0.62%     
  Complexity      426      426              
============================================
  Files          2116     2150      +34     
  Lines         94178    95356    +1178     
  Branches      12492    12699     +207     
============================================
+ Hits          61349    61531     +182     
- Misses        27844    28817     +973     
- Partials       4985     5008      +23

Impacted Files	Coverage Δ	Complexity Δ
...rinalang/stdlib/encoding/nativeimpl/EncodeHex.java	100% <ø> (ø)	0 <0> (ø)	⬇️
...alang/stdlib/encoding/nativeimpl/DecodeBase64.java	100% <ø> (ø)	0 <0> (ø)	⬇️
...rinalang/stdlib/encoding/nativeimpl/DecodeHex.java	100% <ø> (ø)	0 <0> (ø)	⬇️
...alang/stdlib/encoding/nativeimpl/EncodeBase64.java	100% <ø> (ø)	0 <0> (ø)	⬇️
...ava/org/ballerinalang/stdlib/crypto/Constants.java	0% <ø> (ø)	0 <0> (ø)	⬇️
.../stdlib/encoding/nativeimpl/ByteArrayToString.java	77.77% <ø> (ø)	0 <0> (ø)	⬇️
...lib/runtime/nativeimpl/InvocationContextUtils.java	88.57% <100%> (ø)	0 <0> (ø)	⬇️
...ng/stdlib/encoding/nativeimpl/EncodeBase64Url.java	100% <100%> (ø)	0 <0> (?)
...ang/stdlib/crypto/nativeimpl/DecodePrivateKey.java	58.13% <100%> (+0.99%)	0 <0> (ø)	⬇️
...a/org/ballerinalang/stdlib/crypto/CryptoUtils.java	66.16% <29.62%> (-9.31%)	0 <0> (ø)
... and 75 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 105430c...5c581d9. Read the comment docs.