Does Camel-Http4 supports Basic Authentication?
Followed this and other posts
Camel http4 download file using Basic authentication over Https
I am using camel 2.17.3 version. using camel-http4 component. The route sends a https4 multipart request to a REST endpoint . The REST service is behind the siteminder. Have truststore/ketstore/cert all setup and it works fine, just sending basic auth is causing trouble.
Using postman i was able to call REST services with basic auth. However, all the calls from camel route fails and get HTTP error 403.
I tried below options to get it working:
Added basic auth to the HttpConfiguration - got HTTP error 401
Added "Authorization" header to the route, as mentioned in the above link - got HTTP error 403
and Added method,user,pass to HTTP_Query - 403 also clear text password is visible in the siteminder logs, this is not good, so dropped trying this option.
please help resolve this issue with some working example and explain the cause.
Is camel dropping http headers?
also i now thinking should I consider using other available components netty/jetty/cxf?? But I prefer getting HTTPs4 working :)
thanks
To help others with an working example, here is how I got it...
1) Check the site-minder policy and also ensure the user have correct permissions for the services.
2) Passing user/password as query parameter isn't safe (at least it wasn't in my case) Clear text password was exposed in site-minder.
3) setting header (Authorization)
apache-camel-basic-http-auth
Related
I created a Rest-API and a frontend as a self contained system with Quarkus.
The frontend is served statically.
For Authentication i use a kleycloak server and have nearly the same configuration as in this guide from quarkus.
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
With this config i need to authenticate for the rest-api and the frontend. Thats what i want.
If i try to load the index.html i got redirected to keycloak and back. That works perfectly.
The problem is, that the same thing happens with the rest-api. I got redirected to keycloak with a "302 found"-status code. Here I would like to have an authentication with a bearer token and no redirect. Quarkus has the following configuration for this:
quarkus.oidc.application-type=service
That collides with the configuration for the frontend. Is there a way to use both, one for static files and one for the rest-api?
If I'm not wrong you're looking for a multi-tenant oidc setup(even though you're not designing tenants). The guide and example can be found on the official quarkus website here.
This way you'll have similar setup:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
quarkus.oidc.restapi.auth-server-url=http://localhost:8180/auth/your/path
quarkus.oidc.restapi.client-id=backend
quarkus.oidc.restapi.application-type=service
P.S you can replace restapi with more likable name.
Is there any way to remove a header going upstream after the external authentication with the envoy proxy? We planned to migrate to envoy proxy for our internal API gateway, but this is a blocker now.
For example: the external authentication service gets the request and processes the authentication header, in case the validation fails, it throws the 401. But if it succeeds, I want to prevent the auth headers from going upstream.
As per the documentation Ext Auth:
A successful check allows the authorization service adding or overriding headers from the original request before dispatching it to the upstream. This is done by configuring which headers in the authorization response should be sent to the upstream. See allowed_authorization_headers below.
There is no mention whether I can completely remove the header going upstream.
I have the option to override the headers, but that is causing header conflict at the upstream servers. So it is not a possible solution.
How can I achieve this?
Note that I am not an expert in envoy proxy, but from what I was able to find you can actually write a Lua script that would be able to remove the headers. In the documentation you can find an example of such script, and with a little bit of tinkering you should be able to customize it if needed:
-- Remove a response header named 'foo'
response_handle:headers():remove("foo")
You can find more information in the official documentation. Here for config.filter.http.lua.v2.Lua and here are the script examples.
What about using the route level option request_headers_to_remove to remove an Authorization header?
See https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto
I am trying to set up Karate test framework for our new project. We will be enabling Kerberos authentication to our Rest microservices. Can you please tell me if Karate supports Kerberos aunthentication
Most projects are able to call a normal HTTP end-point and get a token from it which will be used as an auth header. So look for the OAuth and header authentication demos / in the documentation.
Otherwise, take a look at this approach: https://stackoverflow.com/a/51150286/143475 - so it is possible for you with a little extra work to call into some .NET code for e.g. which you can design to give you the headers / tokens you need.
I have the following issue.
After upgrading an application to ASP.NET 2.0 I get a 400 (bad request) status response whenever trying to authenticate in production.
This error does not reproduce locally and doesn't reproduce when using the production container locally.
The only difference that exists between production and local is that there is a reverse proxy in production that implements SSL for all requests.
I've tried moving the authentication code from middleware (as it was initially implemented) into a controller and I've changed the path to the route that was used for authentication. I still get the error.
All other requests work fine (provided you have a jwt token attached to them).
I should also mention that the CORS headers aren't set on the 400 response.
Any ideas?
This issue was caused by an upstream reverse proxy that was stripping some headers from the requests. Requests with verbs Post & Put were affected.
Set the log level of your application to Information to see what Kestrel is actually complaining about.
In our case we had to switch hosting providers because of the issue.
I feel like this might be answered already somewhere, but no one seems to have answered this question directly about Drupal and I'm wondering if that might be making all the difference.
I have setup a vanilla Drupal installation with just the necessary modules to use a REST server to handle Push Notifications. In testing the REST server with the CocoaRestClient (found here http://code.google.com/p/cocoa-rest-client/) I am encountering a problem with Basic HTTP Authentication (Authentication is failing). I have tested with Session Authentication and that works perfectly. My username and password are most certainly correct. The Services basic authentication module doesn't provide much in the way of setup, so what could I be doing wrong?
Modules being used:
Push Notifications
Services
Services basic authentication
REST Server
Drupal 7.22 minimal (vanilla install - no themes or any other fancy modules than the ones listed).
Basic auth enables you to GET, POST, PUT, and DELETE, to your endpoints using a Basic Auth Header. I am not sure if it will do anything for the /login end point. The authorization header should be made up of Basic followed by a based-64 encoded string of 'user:password' (not including the quotes).
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
You can quickly test this using Postman or Fiddler.
you need use the content access to restrict the access. This will require users to provide a login and password.