Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I use the signature configuration from the JWT subsystem in wildfly to generate tokens in application code deployed in the same server #9

Open
viktarbelski opened this issue Jul 29, 2021 · 5 comments

Comments

@viktarbelski
Copy link

Assume we build a jwt token and want to use signature encription defined in standalone.xml

<subsystem xmlns="urn:soulwing.org:jwt:1.0">
...
<secret-key name="yourbunnywrote" id="1863" type="AES" length="256" provider="FILE">
<properties>
<property name="path" value="${jboss.server.config.dir}/signature-secret-key"/>
</properties>
</secret-key>
...
<signature name="figvam" algorithm="HS256" secret-keys="yourbunnywrote"/>
<validator name="default" issuer="iss" issuer-url="https://iss" audience="test-service" expiration-tolerance="90" signature="figvam"/>
</subsystem>

How can I get a signature config from server configuration and use it when I build a signature like below

final JWTProvider provider = JWTProviderLocator.getProvider();
	    final Instant now = Instant.now();
	    final Instant expires = now.plus(60, ChronoUnit.MINUTES);
	    final Claims claims = provider.claims()
	        .id("0")
	        .issuer("iss")
	        .issuedAt(now)
	        .expiresAt(expires)
	        .subject(user.getName())
	        .audience("test-service")
	        .set("uid", user.getId())
	        .set("eml", user.getEmail())
	        .build();

	    String token = JsonObject.EMPTY_JSON_OBJECT.toString();
		try {
			token = provider.generator()
			    .signature(provider.signatureOperator()
			        .algorithm(ALG_FROM_CONFIG)
			        .keyProvider(SECRET_KEY_FROM_CONFIG)
			        .build())
			    .build()
			    .generate(claims);
		} catch (Exception e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

I mean is there a convenient way to get SECRET_KEY_FROM_CONFIG and ALG_FROM_CONFIG in code?

@ceharris
Copy link
Member

ceharris commented Jul 29, 2021

Confirming that I understand your question:
How can I use the signature configuration from the JWT subsystem in wildfly to generate tokens in application code deployed in the same server?

@viktarbelski
Copy link
Author

@ceharris correct

@viktarbelski viktarbelski changed the title What is a best way to build a signature How can I use the signature configuration from the JWT subsystem in wildfly to generate tokens in application code deployed in the same server Jul 29, 2021
@ceharris
Copy link
Member

ceharris commented Jul 29, 2021

The JWT extension is generally used in an application setting where you want the Java EE container (Wildfly) to do JWT validation. Consequently, it doesn't provide much help here for generating tokens, since this is usually done in a separate OAuth2 authorization server.

It is possible to get the Wildfly subsystem configuration into a deployed application. One could put the right Wildfly management modules onto the application class loader (e.g. using jboss-deployment-descriptor.xml) and then use Wildfly API to get a reference to the subsystem instance in the management module and access its state. It's probably not all that convenient, but it is doable.

Alternatively, the application could use the same s2ks module that the JWT subsystem uses to load the key material, and with some judicious use of environment variables you could avoid having to repeat the configuration details in both the subsystem configuration and in the application.

@viktarbelski
Copy link
Author

Got you. And thanks for explanation.

@ceharris
Copy link
Member

ceharris commented Jul 29, 2021

Another approach, rather than using symmetric keys would be to use an RSA key pair. The Wildfly subsystem then only needs the public key part to validate, and your application could have access to the private key. Then the only shared part of the configuration is the name of the algorithm, issuer name, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants