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

Need an AuthenticationBuilder #13

Closed
mfulgo opened this issue Jul 18, 2018 · 7 comments
Closed

Need an AuthenticationBuilder #13

mfulgo opened this issue Jul 18, 2018 · 7 comments

Comments

@mfulgo
Copy link

mfulgo commented Jul 18, 2018

It would be helpful if there was an AuthenticationBuilder, similar to the UserBuilder of the okta-sdk-api.

If one wants to create an authentication proxy or broker application, they need to craft their own AuthenticationRequest with a context (deviceToken) and options. So, the client.authenticate(username, password, relayState, handler) method doesn't cut it.

Also, I believe we'd need a way to set the User-Agent and X-Forwarded-For headers on each request. (Perhaps this should be a separate issue.)

@bdemers
Copy link
Contributor

bdemers commented Jul 19, 2018

Great idea!
Currently you can chain the methods though, so something link:

AuthenticationRequest request = authenticationClient.instantiate(AuthenticationRequest.class)
                .setRelayState("some-relay-state")
                .setUsername("joe.coder@example.com");

It requires a few extra lines though, are you thinking something like:

AuthenticationRequest request = AuthenticationRequestBuilder.instance()
                .setRelayState("some-relay-state")
                .setUsername("joe.coder@example.com")
                .build();

To customize the user-agent just implement a UserAgentProvider similar to this one: AuthnSdkUserAgentProvider

X-Forwarded-For is a little tricker, can you explain that use case in a little more detail?

@mfulgo
Copy link
Author

mfulgo commented Jul 19, 2018

Thanks, I found the instantiate method a little later on. Might be good to add to the readme. It's a viable work-around for now.

A small thing that I ran into with that was when instantiating a subclass, the order of setter calls matters:

// Works
client.instantiate(VerifyPassCodeFactorRequest.class)
  .setPassCode(passCode)
  .setStateToken(token);

// Does not compile
client.instantiate(VerifyPassCodeFactorRequest.class)
  .setStateToken(token) // returns a VerifyFactorRequest
  .setPassCode(passCode); // No such method on VerifyFactorRequest

My app is essentially acting as a login portal / gateway...
The X-Forwarded-For header requirement comes from the Okta API docs (See also.):

Okta supports the standard X-Forwarded-For HTTP header to forward the originating client’s IP address if your application is behind a proxy server or acting as a login portal or gateway.

Similarly, I need to set the User-Agent per request, which looks like it gets a bit tricky with the AuthnSdkUserAgentProvider:

If your application is acting as a gateway or proxy, you should forward the User-Agent of the originating client with your API requests.

@bdemers
Copy link
Contributor

bdemers commented Jul 19, 2018

All good points.
I'll get back to you on the headers 🤔

@jmalickenexient
Copy link

@bdemers What is the update on this? The ability to send a X-Forwarded-* header and User-Agent header containing the originating client User-Agent is needed to follow the Okta guidance on implementing a gateway application like @mfulgo mentioned.

@bdemers
Copy link
Contributor

bdemers commented Feb 19, 2019

@jmalickenexient no update yet.

Your comment will help us prioritize this though, Thanks!

@robertjd
Copy link
Contributor

robertjd commented Oct 6, 2020

@bdemers does this new README section cover what was needed by this issue? https://github.com/okta/okta-auth-java#setting-request-headers-parameters-and-device-fingerprinting

@mfulgo
Copy link
Author

mfulgo commented Oct 6, 2020

From my perspective, I think this issue is addressed with the RequestContext and the new README section.

@mfulgo mfulgo closed this as completed Oct 6, 2020
Okta OSS Java automation moved this from To do to Done Oct 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Okta OSS Java
  
Done
Development

No branches or pull requests

4 participants