Set up a proxy between multiple user machines and Okta for authentication - spring-boot

We are using Okta Customer Identity with our application. The challenge with our architecture is that each user gets their own server and subdomain, which is a little weird for Okta, because each redirect URL needs to be provided as part of the application configuration. As we add new users, the list of redirect URLs continues to grow, one per user machine. Their API is not really designed for this, so we have to write the complete list of redirect URLs with every change.
We would like to find a way to use a proxy for the Okta authentication, so that we can just have a single redirect URL for the Okta application configuration. But we're using https://github.com/okta/okta-spring-boot, and we're not really sure how to make it work with a proxy.
If we set up an HTTP proxy using -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=8080, that's going to affect all HTTP traffic, which is not acceptable.
Is there a way we can use an HTTP proxy purely for the Okta auth only, leaving all other HTTP traffic unproxied?
Is there something we can do with the Okta Spring Boot library that would make it possible for all user machines to share a common proxy machine?
The final alternative would be to write some "active" proxy code that runs on the proxy which handles the requests and forwards them on to Okta. It would have to introspect the Okta response and pass it back to the right user machine.
Is there a way to do #1?
Failing that, is there a way to do #2?
If neither of those are possible, are you aware of an existing implementation of #3?

Related

outbound propagation of oidc access token in Liberty

Hello I manage 2 Liberty servers that serve UI and BFF content respectively and I want to secure them both with corporate oidc OP. Having heard about inbound propagation, I was thinking in propagating the access token from UI to BFF.
However I didnt find documentation on how should I configure it to outbound propagate the access token after successful authentication. The documentation only refers to inbound propagation. Only thing I see is a WASOidcClient_*** cookie being set, which I know nothing about it.
I also heard about jwtSso-1.0 feature and tried to create my own JWT with the necessary user information, but can't make this feature get the desired claims from the ID Token (already opened this other question).
So I'm unclear of:
Am I designing this correctly?
How can I get the UI Liberty propagate access token after successful authentication, preferably without coding anything?
Should I propagate access token, or IDToken? BFF needs basic user information that is present in IDToken
What is the WASOidcClient_*** cookie for? Can it be used by different Liberty instances to authenticate requests? Is the name configurable? Im just curious, because this cookie is probably proprietary and not portable, not much desired.
Appreciate it in advance!!

Securing SpringBoot API for desktop application client

I have a SpringBoot Micro-Service based backend API that uses Zuul as a gateway proxy between a JavaFX Desktop Application. Right now there is no security in place, but I am looking to secure the backend with Spring Security, however, every tutorial I seem to run across seems to be based on web-apps and I haven't seen anything for my particular use case. I don't know much about spring security but would like to know if I can accomplish my goals with it, and if so, what modules or examples should I be looking for.
Goals:
Provide a way for my API to know that requests are coming from the desktop app itself, I think the technical term for this is assigning the desktop app a client id and then having the Zuul Server validate that the client id is that off the desktop app before accepting the request. This should be the case for all requests
Only allow API traffic through the Zuul Proxy, all of the downstream requests to the micro-services behind the Zuul gateway should only be accepted if they are coming from the Zuul Server itself.
Allow requests for logging in and registering as a new user without any type of security other than the desktop client id discussed in 1.
When a user provides a successful username/password on login, they are returned a JWT which is then stored in the JavaFX application and used for all of the other requests to the backend.
Configure the token to expire after a specific time frame, say like 90 minutes and provide a method for automatically refreshing an expired token as long as the users account is still valid. For this, I don't want the user to have to re-login, I just want it to check behind the scenes to make sure their account is still valid and then issue a new token if needed.
Have user based roles so certain features, methods, endpoints, etc. are only accessible to users with the valid role. Within the GUI these features will be hidden or disabled, but I would still like a layer of security on the server side to protect against unwanted access in case someone was able to modify the app.
I am just writing down answers to each of your goals :
Passing the client Id in every request from desktop application doesnt make sense, instead you client Id and secret can be passed during authenticaiton call, Like we have in Oauth 2.0 framework. Rest https calls should be made from client, So to avoid tampering of request, You can also go for mutual SSL between your client application and Zuul API gateway, It assures that call is coming from Desktop client only.
Yes, Zuul api gateway should be single entry point to your application, Your internal microservices should not be exposed to public.
For user registeration, Client authentication can be achieved using client Id and secret
Correct, You can also create http only cookie at backend, which will include your jwt token only.
Token refresh can be achieved at zuul api gateway, if session is active, make call to refresh token endpoint to get new access token.
On server side, At zuul proxy you can validate the incoming bearer token expiry along with signature validation, with generic claims too. Now at microservices level spring security can be used for role based access control for particular methods.

Autorization Code Flow with REST API "backend" on a different domain

We are using OIDC and IdentityServer in an enterprise deployment where at the moment we control everything (OP, clients, resources, users).
We have an SPA client that connects to its "own" API and will go through it for everything it requires to do. They are however being served from two different domains. (Let's say the application runs on "my.apps/app" and the API in "my.apis/api").
In our current setup, we use Implicit Flow to have the user authenticated in the SPA and then call the API and verify the token within it. This works very well.
We treat our API as a "resource" even though we don't need to and we don't require the user to give consent.
As mentioned, the SPA needs to go through the API for everything it does and this also includes augmenting user properties upon authentication, so the client doesn't even really let users work with it without going through the API.
Given that scenario, our thinking was that we could even be using Authorization Code flow for our OIDC authentication (treating the API as a backend) and get the security "benefit" of the browser never having access to the tokens.
However, due tue the applications being hosted separately we think this would require us to either:
Initiate the authentication request in the SPA, get the Authorization Code in the fragment but pass it later to the API which will in turn request the tokens and have them live in a cookie or something along those lines.
Initiate the authentication request in the SPA but use redirect_uri to the API domain, thus giving the Authorization Code to it which will request the tokens, have them live in a cookie and then redirect to the SPA again.
Basically we want to know if this is a setup that you think would work, what are the security concerns if any, and if it would be recommended for us to go ahead with this or to keep using Implicit Flow instead (specially from a security standpoint).

Should HTTPS be used for all calls involving authorization

It's common to use HTTPS for authentication, so the authentication details from client cannot be sniffed. However once the user is logged in then subsequent calls to a web app passing some sort of auth id which then the web app will then use to authorise with, should that not also be HTTPS? How is this done in things like Facebook? Seems easier to make all traffic HTTPS.
An answer by Jeff Atwood:
http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html
Assuming the server can handle it, I'd go a step further and use SSL for everything, no matter if users are logged in or not.
This has the advantage that an eavesdropper doesn't even know if the user is accessing your site/app as a guest or as an authenticated user. It also saves you from having to decide when to use SSL and when not.

How to design authentication and authorization system for REST backend / Ajax front End Application

I am starting a new project where we are planing to build a restful back end and an AJAX font end. I am approaching the problem by focusing on Identifying all the resources that I have and what the various HTTP verbs will do them, their URI and the JSON representations of those resources.
I am looking for the best design for securing the backend. Here is the list of designs I have considered. I am looking for alternative designs not listed below, and pros, cons recommendations. The system will be implemented with Spring 3.0 and possibly Spring Security 3.0, SSL will be used for many parts of the system but not for all of them, so some requests may come on SSL and some might not.
Option 1: Use the HTTP session
Show a standard login screen, create a server side session and let tomcat send back a jsessionid cookie and have the ajax client include the JSESSIONID cookie on every XHR request. This options just feels like it's the wrong approach for the following reasons.
The connection becomes statefull which is against the rules of REST
I want to be able to split the bakcend into multiple seperate WAR files which means i could have multiple HTTP sessions on the backend, if that is the case then this approach does not work. While I don't need the ability to split the backend into multiple apps today, I would prefer a design that allows for that possibility.
Option 2: Find an open source Java based security library that does this
Other than Spring security I have not found any other Java libraries, any recommendations are highly appreciated.
Option 3: Try to use an existing protocol like OAuth
In my very brief look at OAuth it seems that it is designed for authentication across sites where each site has it's own user database. In this system i want a global user database shared across all the backend ajax services.
Option 4: Use SAML and Shiboleth
This options seems over kill and hugely complex to setup and maintain.
Option 5: Send the username and password with every request
This requires that user sends their username and password with every request, which means that the front end AJAX app must store the username and password as a JavaScript object and if the user navigates away from the page then back the username/password combo will be gone and the user might be forced to log in again. I don't want the front end to try and put the username and password into cookie as that would comprise security.
Option 6: Implement my own authentication / Authorization protocol
Create a REST service that users can present their username/password combination to and then get back and security token, which they must send back to the service with every request. The security token would be digitally signed by the service and would have an expiry time. The token would be only good for most operations high security operations would require a new login screen as port of confirming the operation.
Problem with this approach is I have to invent yet another security protocol which seems like a total waste of time.
I am sure I am not the only person up against this problem, I hope the stack overflow community can point to some options and tools that I have not found yet.
Take a look at Apache Shiro. It is an authentication system that has a session management feature that can be used to share sessions across applications. This may be the easiest thing to do.
Or you could use Spring Security (or Shiro) with a Remember Me cookie that is shared across the webapps (as long as they are in the same HTTP domain). The remember me cookie would be analogous to your token in option 6. You can set the expiration on the cookie that so it is short lived like a session cookie or long lived like a regular remember me.
You might also want to take a look at Jasig CAS - Single Sign-On for the Web. It has a REST API and a protocol (Proxy Tickets) that allows services to proxy user AuthN to backend services like you described in option 6. http://www.jasig.org/cas
Briefly...the application that serves up the AJAX client is protected with Spring Security (supports CAS out of the box) and gets a Proxy Granting Ticket that you embed in the AJAX client. The AJAX client uses the PGT to get Proxy Tickets for your REST services...protected with Spring Security too. The REST services get an authenticated userId without every touching primary credentials.
Alternative, you could keep the PGT on the server and use AJAX calls to retrieve Proxy Tickets that are then used by the AJAX client to call you REST services.
As I understood you are going to secure a rest application, to preface you must know that a security provider consisd of three concepts (3A):
-Authentication
-Authorization
-Auditing
to implement these three together you must provide bunch of tools such as :
-SSO provider
-Session Store
-Open Id pattern
-user credentials integration
....
I have used ACL(Spring ACL) to provide authorization services and oauth2 for authentication.
there is one channel to connect these two together and its scopes(oauth2 scopes) but the problem is scopes are not flexible(pure strings) enough to implement authorization modules such as role_voter, cache_strategy, black_list or,Role_base strategy, exceptional permissions, white_list... (but you can use #EnableGlobalMethodSecurity)
In my case I used authorization server as a resource for oauth2 authentication server(take a look at http://projects.spring.io/spring-security-oauth/docs/oauth2.html), then I considered two spots to check authorization, the first I issued ACL to front-end and forced programmer to design her page dynamically up to ACL concept, the second is in back-end on service layer(BLL) using Aspect when one rest is going to be called. I sent the service key as an actee to check if current user has enough access control to do that. and for auditing you must monitor all requests I mean you must use an listener in your gateway or broker...

Resources