I'm looking to do 3 legged oauth on istio+kubernetes. I did not find a way to route unauthenticated requests to an authentication proxy service which performs the authentication and route the traffic back to the target service. I've done this with nginx kubernetes ingress controller using the following annotations -
nginx.ingress.kubernetes.io/auth-url //Auth url that requests will be forwarded to
nginx.ingress.kubernetes.io/auth-signin //Sign in page the request is routed to when the above returns 401
I did not find equivalent ones in Istio. I've checked the documentation and it says it supports custom auth in addition to jwt, however I did not find any such support.
Answering my own question.
At this point I've figured out the only way to do this is via EnvoyFilter on istio. This allows us to write a custom lua filter to to route unauthenticated requests to an oauth proxy which can perform 3-legged oauth flow.
The request control flow is
client --> ingress gateway --> istio-proxy sidecar --> envoy filter --> target
The filter is capable of making http calls and manipulate headers, which fits this requirement.
Edit:
Details about it are here.
Related
I am authenticating against an OAuth2 service that provides me 3 endpoints:
http://bobsoauth.com/oauth2/authorize
http://bobsoauth.com/oauth2/token
http://bobsoauth.com/oauth2/userdata
This service DOES NOT issue JWTs.
I need to use an Angular client application, connecting to a Spring Cloud Gateway, which in turn connects to multiple Spring Boot microservices.
Without JWTs, can I still use a token relay setup between the gateway and the microservices?
Without JWTs, you'll have to configure your resource-servers with token introspection (http.oauth2ResourceServer().opaqueToken() instead of http.oauth2ResourceServer().jwt() in spring-security conf). This is far less efficient than JWT decoding because each micro-service has to submit token to authorization-server for each and every request it processes.
Sample here: https://github.com/ch4mpy/spring-addons/tree/master/samples/tutorials/resource-server_with_introspection
The endpoint is usually called introspect, but I guess you'll have to figure out a way to use userdata in your case.
Have your Angular application authenticate against your authorization-server, and use the gateway just to forward Authorization header.
For Angular, I use angular-auth-oidc-client. Just put in the conf the URLs you mentioned in your question.
I am calling a third party API which needs authorization header with Basic base64 encoded (for the third party API). I also have to do proxy authentication with my company's proxy server with Basic authentication (with service account with AD authentication).
The issue I am facing when I send both of the properties proxy forward the request with the service account to the API not the Authorization header. Has anyone else faced similar issues. Please advise.
Below are service which is running on the system:
Rest client service: client assesing the rest backend service.
Api gateway: all rest client request will go through gateway.
Session manager service: Service which is holding the global session in the system.
Authorization service: Service which make the decision, whether current global can perform the operation.
Rest backend service: this is a kind of backend resource service. which only authorized user can access it.
Call flow understanding
-> When rest client application access the the Rest backend service, it is intercepted by gateway. Now Gateway will make rest api call to session Manager service to get the current global session.
-> then Gateway will send the request backend service url and current session to the authorization service. Authorization service will
make the decision if curruent session has authorization to for the request url by the client.
-> if gateway will get success response from authorization service, then gateway will forward the incoming request to the rest backend
service.
Pls find below diagram for more understanding:
Question:
Is it possible to handle those flow using api gateway. if so how?
which gateway will better fit here. Nginx or Kong or anything else.
If possible, can you provide some example or article link which handles such scenario.
I'm trying to use the #EnableOAuth2Sso along with #EnableResourceServer annotation to relay in coming Authorization tokens to upstream services. I can't seem to configure it properly. I don't want or need to really configure the internal oauth2 client to retrieve a token, it should always pull the token from the incoming request. Is this possible to do?
I have an admin-console for an existing service that I want to provide access to by adding login, using our company's OAuth 2.0 service. I want to use Apigee here, so that the web-app with the admin-console does not have to implement the login-logic.
My idea was to use AuthorizationCode flow and let Apigee manage the tokens and I looked into https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, but I really can't see how our existing OAuth service fits in.
Is there a sample like that? Perhaps using Google's or Facebook's OAuth service to authenticate the user?
First, Apigee needs to be a proxy into the admin-console. This means that all traffic to the admin-console has to go through Apigee. Otherwise, you won't be able to enforce authentication.
Second, there are a couple different options for integrating with the external oauth 2.0 service. Apigee has the ability to store an external access token and use it as its own, or Apigee can generate a token and store the external access token as a custom attribute.
High level thoughts on how the Apigee proxy could look like:
ProxyEndpoint - endpoint exposed to clients connecting to admin console
TargetEndpoint (not shown in that oauth login-app example) - endpoint for the actual admin console
The flows that execute in the Apigee proxy before sending the request to admin-console will need to implement logic that checks an authentication token. If it's valid, let the request pass onto the TargetEndpoint (admin-console). If the request isn't valid, step through logic that goes calls the external oauth 2.0 server's auth code flow. This will require the following:
Apigee needs to be registered with external oauth 2.0 server.
Logic needs to be built in this proxy to support the redirection based flow of authorization code grant_type (obtaining auth code, receiving the auth code, obtaining token --> all while being redirection based and transparent to user).
In addition to #2, Apigee will need to store the external token as custom attribute and expose the apigee token, or store the external token for verification purposes later on. http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-20 (see Delegating token management). After the token is stored, you'd need to respond with another 302 redirect to the initial uri + token so the request can pass through to admin-console as an authenticated request.
#2 isn't exactly straight-forward and there won't be an example proxy that shows this implementation. If the oauth 2.0 service supported a password grant, it may simplify the implementation, but allows the credentials to pass through apigee and not directly with the authorization server.