Spring Security SAML HTTP Post error with OpenAM - spring-security

I am having an issue with the Spring Security demo by Vladimir. When I change the binding and assertion consumer service to HTTP-POST by default, I get the following error...
IDPSSOFederate.doSSOFederate: Unable to do sso or federation.
com.sun.identity.saml2.common.SAML2Exception: Cannot resolve element with ID xxxx
...as a result of an XMLSignatureException.
I have noticed that OpenAM is trying to redirect me to http://localhost:8080/SSOPOST/metaAlias/idp however in the IdP metadata it is specified as http://localhost:8080/openam/SSOPOST/metaAlias/idp.
Obviously I am getting a 404 error but I can't work out why it is redirecting me to an SSOPOST url without the application context.
Scrolling up the logs I can see an earlier getRemoteServiceURL NullPointerException but from what I have read this is part of normal OpenAM logs?
My configuration authenticates fine to OpenAM with the default SOAP settings. Why would HTTP-POST be any different?

Just to let everyone know, I contacted ForgeRock and worked through the issue with them. This problem is related to the following issue: https://bugster.forgerock.org/jira/browse/OPENAM-2644
It is actually a bug in OpenAM which was exposed with the latest Java update (version 1.7.0_25). The temporary solution (until OpenAM 10.2 is released) is to revert back to a previous version of Java.
Reverting to Java version 1.7.0_21 fixed the issue for me.

Related

What is the best way to configure swagger with keycloak + wildfly?

I have already configured Keycloak role based access control with my java API project and it is deployed with Wildfly and runs without any errors. Since I have tested and confirmed the responses with Postman, I needed to use Swagger in-order to generate API documensts.
Using Swagger Inspector I created an API definition and exported that via SwaggerHUB to use it in SwaggerUI which I run locally. With web-origins and all the necessary steps configured in Keycloak and with authentication parameters set in Swagger script, I get the below error..
"
Access to fetch at (api request) from origin (swagger ui path) has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
"
I have noticed that if I bypass Keycloak, this works. What might be the best solution to overcome this issue?
I was able to resolve my issue referring this answer. I too added "enable-cors": true in keycloak.json in my Java back-end server which was Wildfly and tested the same implementation in server environment successfully.

Springdoc OpenAPI ui does not honor context-path in "location"

Setup:
I am using the Java library springdoc-openapi-ui in version 1.4.0 (via Maven) without any customization in a simple spring-boot project.
The Swagger page is generated under
https://my-url.com/my-context-path/swagger-ui/index.html
and the api-docs under
https://my-url.com/my-context-path/v3/api-docs/
both of these work and I can reach them. So far so good!
Now the problem:
When simply navigating to https://my-url.com/my-context-path/swagger-ui.html I am getting a HTTP Status 302 and a location attribute set in the response header that is supposed to redirect me to the swagger page from above (I assume).
However, the URL in the location attribute misses the context path! It looks like this:
https://my-url.com/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config
It redirects to a page that does not exist and I am getting a 404 error code. Note, that the configUrl also seems to be missing the context-path.
Any ideas why this occurs and how it can be fixed?
This Github Issue seemed to be the same problem, but in the end it is stated that the problem is fixed: https://github.com/springdoc/springdoc-openapi/issues/37 and that is for a previous version than mine.
Okay so the issue is that springdoc-openapi-ui is unaware of your app context path unless it is defined in spring boot, which may not be possible for everybody.
Hopefull it does support the non-standard header X-Forwarded-Prefix that can be sent by your gateway.
I my case (Kubernetes), the Ingress can be configured in your chart by simply adding nginx.ingress.kubernetes.io/x-forwarded-prefix: "true"
And in your application config you also need to specify
server:
forward-headers-strategy: framework
to use Spring's support for handling forwarded headers.
Sources:
https://github.com/kubernetes/ingress-nginx/issues/3670
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#x-forwarded-prefix-header
https://github.com/springdoc/springdoc-openapi/issues/607
There are no know issues about context-path usage. As you can #37 is resolved and that reported it has confirmed that!
Just make sure you follow the instructions of setting context-path on standard spring-boot application.
You can test the configuration of your context path, in the different demos samples:
https://github.com/springdoc/springdoc-openapi-demos
If you have any problem, you can log an issue by provinding a minimal/reproducible sample or with unit tests that reproduces the problem.
In order to configure a swagger-ui correctly when an external context-path is configured use the follow configuration.
springdoc.swagger-ui.config-url=/context-path/api-docs/swagger-config
springdoc.swagger-ui.url=/context-path/api-docs
springdoc.api-docs.path=/api-docs

Swagger UI - " TypeError: Failed to fetch" on valid response

I've just pulled down the latest Swagger from the Git repo (3.0.19) using: https://github.com/swagger-api/swagger-ui.git and updated my API to use the new version.
Ran git describe --tags to confirm and my version is currently: v3.0.19-6-gaab1403
The problem I'm having is one described here, whereby my response is a 403 (I can see this in the inspector on the browser) and although I have a reponse for error 403, I still get the TypeError: Failed to fetch message.
Here's a snippet from my definition regarding the 403 response:
"403": {
"description": "Forbidden",
"headers": {
"Access-Control-Allow-Origin": {
"type": "string"
}
}
},
I've also noticed it reported here however, I know it's not a CORS issue as I have tested the endpoints and the OPTIONS are returning correct, as are the endpoints if called with valid information (I force this 403).
Could anyone point me in the right direction please?
Update: I have since tested on a 401 response, with the same response.
And that a 400 is working as expected:
For anyone that runs into this problem;
After a day of troubleshooting and the Swagger support guys pointing me in the right direction, it turns out that this is currently caused by a bug within the AWS API Gateway custom authorizers.
We are currently using AWS API Gateway for managing our APIs, this includes managing all our authorization via a custom authorizer. The issue is that custom authorizers do not currently support passing through headers within the response and Swagger UI needs the Access-Control-Allow-Origin:* within the response header(s) to display the correct HTTP status code.
See this AWS thread regarding the issue (which is older than a year already):
https://forums.aws.amazon.com/thread.jspa?messageID=728839
Swagger UI discussion on same: https://github.com/swagger-api/swagger-ui/issues/3403
EDIT / UPDATE
This has since been resolved with the use of Gateway Responses. See this same forum (page 2):
https://forums.aws.amazon.com/thread.jspa?messageID=728839
I hit this error during local development (i.e., had nothing to do with AWS). The underlying cause (CORS violation) is identical. The following might help others who encounter this problem.
I setup connexion with an openapi spec that referred to http://localhost:9090/. When the development server starts, it says "Running on http://0.0.0.0:9090/". That page appears to work, but the swagger ui uses http://localhost:9090/ from the openapi spec for subsequent requests and shows TypeError: Failed to fetch in results. The browser console shows Access to fetch at 'http://localhost:9090/vr/variation' from origin 'http://0.0.0.0:9090'. The provided curl command worked fine; although initially confusing, the curl success is a clue that the problem is due to browser blocking rather than server-side failure.
(Connexion is based on Python flask and provides extended support for openapi integration.)
I had the same issue and there was a very simple fix. I accessed my site using HTTP but it required HTTPS. My site was redirecting to HTTPS when calling an endpoint.
This violated the "same-origin policy":
https://learn.microsoft.com/en-us/aspnet/core/security/cors?view=aspnetcore-2.2
Disclaimer:- This answer is for APIs developed using Asp.net Core
I have faced similar issue when trying to access the APIs from the Swagger UI Editor.
I was trying to access some APIs developed using Asp.net Core where as the Swagger UI Editor was hosted on Apache. I was facing CORS (Cross Orgin Request).
I have to modify my APIs code to allow CORS request using following code:-
Declare within Startup.cs File having class "StartupShutdownHandler"
private readonly string MyAllowSpecificOrigins = "_myAllowSpecificOrigins";
Added a section of code within ConfigureServices Method.
var str = ConfigurationHandler.GetSection<string>(StringConstants.AppSettingsKeys.CORSWhitelistedURL);
if (!string.IsNullOrEmpty(str))
{
services.AddCors(options =>
{
options.AddPolicy(MyAllowSpecificOrigins,
builder =>
{
builder.WithOrigins(str);
});
});
}
Added a line of code within Configure Method.
app.UseCors(MyAllowSpecificOrigins);
Reference Enable Cross-Origin Requests (CORS) in ASP.NET Core
Because the problem of cross-origin means your website is hosted on either locally or with port 8000 or different port, and your swagger's port number is different, so this problem is genuine. We can fix it by giving permission.
Here is the node code:
app.use( (request, response, next) => {
response.header("Access-Control-Allow-Origin", "*");
response.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
next();
});
We can solve by using CORS npm as well.
https://www.npmjs.com/package/cors
Please check the swaggerOptions provided to swagger jsdoc and check whether host and base name is correct. I have encountered the same issue before and got fixed the issue by correcting this. Hope this will also solve the problem.
Eg:
const options = {
swagger: "2.0",
swaggerDefinition: {
// options.swaggerDefinition could be also options.definition
info: {
title: "Customer API", // Title (required)
description: "Dummy Customer API for implementing swagger",
contact: {
name: "Stack Overflow"
},
version: "1.0.0" // Version (required)
},
host: "localhost:5000",
basePath: "/"
},
// Path to the API docs
apis: ["SwaggerImplementation/index.js"] // For complex api's pass something like apis: ["./routes/*.js"]
};
I have encountered the same error while trying to authenticate access OAuth2 secured Rest API set. API server deployed on VM and was connecting to it using IPSEC VPN. Actually username/password in HTTP header with basic authentication was sent using separate API other than /oauth/token, backend itself was calling http://localhost:8080/api/v0/oauth/token with client secret and returning back token to client. After changing localhost to server's actual local IP , problem disappeared.
This error is generic on swagger side and could be due to many possible reasons.
In my case, it was due to connection error. My swagger page was not responsive due to connection issue at my side. I had to refresh it once and worked for me.
If it's a .NET Core API, try commenting out the below method call in the StartUp.cs
Like below,
// app.UseHttpsRedirection();
It's because some times your IIS Binding's HTTPS SSL Certificate will automatically goes to Not Selected. So again you haveThere was a similar question raised and there are few good answers Please refer this link to manually selectget the SSL Certificates to1 IIS Express Development Certificate1. Below I have mention how to doanswer:
Open IIS Click Default web sites.
In the right side corner you will see a some setting click "Bindings", you will get a Site Binding window.
Then you will get http and https details.
In that Click "https" and click edit, then you will get another window Edit Site Bindings.
In that window check SSL Certificates.
If SSL Certificate = Not Selected select IIS Express Development Certificate.
Then stop and Start the IIS.
Issue will be solved.
Below article might help.
I was facing same issue when from Swagger ui calling API Gateway which further calls Lambda function using proxy integration (which passes response headers from lambda). In my case I missed to set response headers Access-Control-Allow-Origin in Spring boot app lambda handler response-event object APIGatewayProxyResponseEvent. After setting this header in handler class, Swagger UI was able to call api gateway. See
https://fanchenbao.medium.com/thanks-for-the-article-it-is-a-great-way-to-get-started-with-deploying-swagger-ui-on-s3-7990c7b48851
you can use modheader extension in order to fix it
For .NET Core 2.1 or above
In Startup or Program, register configuration to IApplicationBuilder to
app.UseCors("AllowAll");
Every solution will definitely be correct :)
But in my case I have that line in my webconfig file
<environmentVariable name="ASPNETCORE_HTTPS_PORT" value="5001" />
I just replace ASPNETCORE_HTTPS_PORT to ASPNETCORE_HTTP_PORT and the error has been gone :). So the final line is
<environmentVariable name="ASPNETCORE_HTTP_PORT" value="5001" />
replace 5001 with your port.

Server not found after external login MVC

Hello I use the code from https://coding.abel.nu/2014/11/using-owin-external-login-without-asp-net-identity/
and I was getting the error "The page isn't redirecting properly". after I login to my provider.
I clear my cookies but now when I log in to my provider but I get "Server not found". "Firefox can't find the server at login;jsessionid=f09ba421eeee23eab2a1ffa8b6ed35c3." in the url it returns https://login;jsessionid=f09ba421eeee23eab2a1ffa8b6ed35c3/. My provider is CAS. This is for firefox. In chrome it just brings a blank page.
I try it also with Google but I get same errors.
Any idea?
thank you
I believe I had the similar bug, there was one line solution to this bug...
"here is a bug in Microsoft's Owin implementation for System.Web. The one that is being used when running Owin applications on IIS. Which is what probably 99% of us do, if we're using the new Owin-based authentication handling with ASP.NET MVC5.
The bug makes cookies set by Owin mysteriously disappear on some occasions..."
solution here: https://github.com/KentorIT/owin-cookie-saver

401 Returned when authenticate via HttpClient on WebLogic

I have REST based services deployed in WebLogic Application Server 12 which uses Spring Security for authentication using BASIC Auth. Previously I found out that WebLogic has a bug where it intercept a call if request has Authorization header in it.
I found a very helpful link which solves this issue by disabling <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> this in config.xml of WebLogic. Now if I access my service via POSTMan it works great and Spring handles the security.
After this I write some automated test which uses Apache Common HttpClient library to call my service, but I am continuously getting 401 Unauthorised from WebLogic. My client code is as follows;
httpClient = new HttpClient();
httpClient.getState().setCredentials(
new AuthScope(AuthScope.ANY_HOST, AuthScope.ANY_PORT),
new UsernamePasswordCredentials(
getTestUsername(config.getUsername()),
getTestPassword(config.getPassword()))
);
I tried putting auth pref to Basic, adding Authorization header to my request even setting auth to Preemptoive to true everything it still the same.
One thing I am sure is that Weblogic is intercepting my call from Java Standalone client somehow! because in Response Headers i get 'realm: weblogic' which is incorrect as it should be 'realm: Spring Security Application', more strangely I am able to access the same URL from POSTMan with the same security credentials. Am I missing anything?
Yes, I confirm that Weblogic intercepts your call.
You have to enforce the <enforce-valid-basic-auth-credentials> tag to false in your weblogic config.xml file.
Please take a look at Error adding enforce-valid-basic-auth-credentials to config.xml and http://www.dba-oracle.com/t_weblogic_bypass_basic_authentication.htm

Resources