Currently i have configured set-uri like below in resource server & spring cloud gateway,
spring.security.oauth2.resourceserver.jwt.jwk-set-uri: http://dev.auth.server:9999/.well-known/jwks.json
However to achieve high availability, I would like to resolve this end point from eureka server, I have successfully registered my auth server in eureka but below configuration fails,
spring.security.oauth2.resourceserver.jwt.jwk-set-uri: **lb://auth-server**/.well-known/jwks.json
could anyone please suggest?
currently there no way to achieve high availability by directly setting auth-server in jwt.jwk-set-uri instead you can achieve this by routing through spring cloud gateway
spring.security.oauth2.resourceserver.jwt.jwk-set-uri: GATEWAY_SERVER_URL/.well-known/jwks.json
in gateway config, you would have a config like this, which will load balance for you automatically.
- id: oauth-server
uri: lb://auth-server
predicates:
- Path=/.well-known/jwks.json
Related
I'm trying to connect to Microsoft Power BI using the Mule Power BI connector but the connector configuration is very confusing with respect to OAuth. Has anyone successfully connected to Power BI with Mule? Here is my config:
<power-bi-rest:config name="Power_Bi_Rest_Connector_Config" doc:name="Power Bi Rest Connector Config" doc:id="d9dbee0f-50fe-46ca-977e-2b3c6ce1ff3b" >
<power-bi-rest:oauth2-authorization-code-connection >
<power-bi-rest:oauth-authorization-code consumerKey="xxx" consumerSecret="yyy" authorizationUrl="https://login.microsoftonline.com/69f2560d-6d2a-4768-989e-d35ed85aeab2/oauth2/v2.0/authorize" accessTokenUrl="https://login.microsoftonline.com/69f2560d-6d2a-4768-989e-d35ed85aeab2/oauth2/v2.0/token" scopes="api://96eb9d1c-6dfb-4acf-9950-d4af04038693/Mule"/>
<power-bi-rest:oauth-callback-config listenerConfig="HTTP_Listener_config" callbackPath="https://login.microsoftonline.com/common/oauth2/nativeclient" authorizePath="https://login.microsoftonline.com/common/oauth2/nativeclient" />
</power-bi-rest:oauth2-authorization-code-connection>
</power-bi-rest:config>
I have not specifically used Power BI but I can tell the what the issue probably is.
The oAUthCallbackConfig is where you will need to make the changes.
External Callback URL: While configuring the OAuth credentials in your MS account, you must have provided a callback URL that should be pointing to your Mule application. You need to put that URL here.
Callback Path: Here you need to mention where the Mule App should be expecting to get the call back with the authorization code. For example of you have configured external path as https://localhost:8082/oauth/callbackthis parameter could be oauth/callback. (Note that you will need to consider the base path that you may have configured in the http listener)
Authorize path: This should not be a URL pointing to a Microsoft api, but it is the path that you will use to hit you mule app to start the oAuth dance. You can put something like /oauth/authorize. Then when you try https://localhost:8082/oauth/authorize the mule app will trigger the oAuth dance and will redirect you to the login screen of everything else is setup correctly.
I made a docker container with a pretty simple web app: https://github.com/liquidcarbon/dockerflask2fa
The whole thing behaves well locally and when you're accessing via the ELB endpoint:
http://dockerflask2faloadbalancer-f10e5f558aaa921f.elb.us-east-1.amazonaws.com:5000
But when I use my Cloudfront distribution that lives on my domain, logging in does not work, returning "CSRF tokens do not match" message on registering a new user, and or logging in as an existing user.
https://flask.albond.xyz
The Cloudfront Cache Policy was set to CachingDisabled.
I'm new to web security, and I'll appreciate your help.
Looks like the caching & cookies behavior needs to be tweaked in Cloudfront: https://github.com/liquidcarbon/dockerflask2fa
I want to implement Oauth2 protocol from scratch for study purposes.
I'm following the Github guide after having created an App with a Client ID and Client Secret.
The two information sources are pretty simple and are:
https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/
https://gist.github.com/technoweenie/419219
In particular, I'm starting from the first step pasting on my browser:
https://github.com/login/oauth/authorize?client_id=&redirect_uri=http://localhost:8080/auth/temp&scope=user&state=&allow_signup=true
I have a Spring application listening on port 8080 (I don't want to use Spring Security because I want to implement the protocol from scratch) with the following and working endpoint exposed:
#RequestMapping("/auth/temp")
public String redirectAuth(HttpServletRequest request) {
//TODO implement next steps
return "here we are!";
}
but when I go to the github link I get a 404 not found error, as my localhost application wouldn't exist.
I expect the official guide has some mandatory information missing, such as some other endpoints which my application must expose in order to be queried, for instance, about the client secret.
So, what am I missing?
Github only supports the auth code oauth 2 flow. It might be helpful to read up on that.
I have a blog and a video on the auth code flow that may help.
Disclaimer: I work at and created them for Ping Identity, but I think
they'll be helpful even for your study purposes.
https://developer.pingidentity.com/en/blog/posts/2019/what-are-oauth-2-0-grant-types-part-1-authorization-code-flow.html
https://youtu.be/eg7I8x-u0sc
You haven't included your client_id in the authorisation url:
https://github.com/login/oauth/authorize?client_id=&redirect_uri=http://localhost:8080/auth/temp&scope=user&state=&allow_signup=true
The authorization server (GitHub) needs this value to identify the client you have registered.
I'm currently working on an API Gateway to centralize calls to REST APIs. We are using Spring Cloud (Edgware.SR3 version), with Zuul (1.3.0) to handle service discovery and Consul as service registry.
In a first version, routes to each service was registered in the gateway configuration using zuul.routes.myApiName.url and it was working fine.
Then, we wanted to use dynamic routing to allow having multiple instances of each API.
I've removed the zuul.routes.myApiName.url for that purpose.
Problem is that my calls to the API through the gateway are returning and error :
Bad Request This combination of host and port requires TLS.
Here is the configuration of the API registering in Consul :
spring.cloud.discovery.enabled=true
spring.cloud.consul.host=#consul_host_ip#
spring.cloud.consul.port=#consul_host_port#
spring.cloud.consul.discovery.scheme=https
And here is the configuration of Zuul route in the gateway :
zuul.host.socket-timeout-millis=60000
zuul.add-proxy-headers=false
zuul.ignored-services=*
zuul.routes.myApiName.path=/myApiName/**
zuul.routes.myApiName.serviceId=myApiName
API is correctly registered in Consul and health check is using HTTPS successfully :
HTTP GET https://hostname:port/health: 200 Output: {"description":"Composite Discovery Client","status":"UP"}
Certificates are also well configured since I am able to call my API directly using HTTPS.
But it seems that Zuul redirection is using HTTP instead of HTTPS (I have the same error if I call my API in direct mode (no gateway) using HTTP).
I've been struggling with this for a while, so I'd like to know if there is a configuration missing to force Zuul to use HTTPS in the routed call to API ?
Thanks in advance !
Just configure
zuul.addProxyHeaders = false
As the proxy headers are added by Zuul while forwarding any request to backend.
I've finally found the solution : I had to add this property :
ribbon.IsSecure=true
I have a Webapp that is secured using Spring Security CAS. The CAS Server and the Webapp sit behind a web server for reverse proxy (named url). The webapp uses ServiceAuthenticationDetailsSource to authenticate dynamic service urls. The problem I have is that Service Ticket validations are failing because the url supplied during validation does not match the url provided when the ticket was created. The set up works without the webserver when systems are connected using https://:/.
The issue seems to be that the web server modifies the HttpServletRequest when redirecting to the webapp where in it looses the "named url" information and is substituted with the and . The service ticket is obtained using the named url via "?service=" during login.
Any possible solution? Can apache reroute request without modifying it, especially for applications that are self identifying or for security reasons where CAS is trying to record the client IP address?
I have outlined a few options below:
Setup the Reverse Proxy
According to the Javadoc of ServletRequest: the HttpServletRequest.getServerName() will be:
the value of the part before ':' in the Host header value, if any, or
the resolved server name, or the server IP address.
This means you can configure your proxy to ensure the Host Header is set properly (Note Some containers like WebSphere do not honor the specification though).
Override using the Container Configuration
Many servers have a setup that can override this value in the event you are using a reverse proxy. There is a pretty decent thread on the Spring forums with a bit more information on it that I have summarized below.
If you are using Tomcat, I'd refer to the Reverse Proxy setup page. One method of configuration would be to configure the Http Connector to have the proxyName attribute to override the value returned by HttpServletRequest.getServerName() and proxyPort to override the value returned by HttpServletRequest.getServerPort(). An example configuration might look like:
server.xml
<Connector scheme="https" secure="true"
proxyPort="443" proxyName="example.com"
port="8009" protocol="AJP/1.3"
redirectPort="8443" maxThreads="750"
connectionTimeout="20000" />
Websphere has a few custom properties that do the same thing.
com.ibm.ws.webcontainer.extractHostHeaderPort = true
trusthostheaderport = true
httpsIndicatorHeader = com.ibm.ws.httpsIndicatorHeader
If you are not using either of these containers or need to support multiple domains, you will need to consult your containers documentation.
Custom AuthenticationDetailsSource
Of course Spring Security is pretty flexible, so you can always provide a custom implementation of AuthenticationDetailsSource that returns an instance of ServiceAuthenticationDetails that looks up the service URL in any way you wish.