I have a problem:
WWW-Authenticate Bearer realm="test", error="invalid_token", error_description="Invalid token issuer. Expected 'http://keycloak:8080/auth/realms/test', but was 'http://localhost:8080/auth/realms/test'"
My settings:
application.yml
keycloak:
realm: test
resource: api
auth-server-url: http://keycloak:8080/auth
ssl-required: external
autodetect-bearer-only: true
cors: true
principal-attribute: preferred_username
credentials:
secret: 2b553733-8d5f-4276-8ace-17112ac7ac20
docker-compose.yml
keycloak:
image: jboss/keycloak:10.0.0
environment:
- KEYCLOAK_USER=admin
- KEYCLOAK_PASSWORD=admin
ports:
- "8080:8080"
networks:
- net
Auth url: http://localhost:8080/auth/realms/test/protocol/openid-connect/auth
Token url: http://localhost:8080/auth/realms/test/protocol/openid-connect/token
I understand why the problem exists, but I don`t understand how to fix it.
Keycloak's Default Hostname Provider (https://www.keycloak.org/docs/latest/server_installation/#default-provider) has a property called frontendURL which should be set as the public URL on which Keycloak is exposed.
Setting frontendURL ensures that all front-channel URLs, like issuer, authorization_endpoint use the configured value as hostname in the URLs and back-channel URLs keep using hostname in the request.
I added 127.0.0.1 keycloak in hosts file and used http://keycloak:8080/auth/realms/*** url to get the token. Now the JWT token contained the issuer as keycloak instead of localhost. I verified the token using jwt.io website. This resolved the mismatch in token issuer.
Related
If I'm trying to connect to my Vault Engine, I get a Error 503 Service Unavailable. If I'm sending the call to a local WireMock which redirects the call with less headers to the same address, it works. Spring Cloud Version is 3.1.1
Cannot enhance VaultToken to a LoginToken: Token self-lookup failed: 503 <html><body><h1>503 Service Unavailable</h1>
The bootstrap config looks like this
spring:
cloud:
vault:
scheme: https
host: <uri-to-the-vault>
port: 443
uri: <uri-to-the-vault>
authentication: token
token: "TOKEN"
enabled: true
kv:
enabled: true
backend: <backend-name>
profiles: <profile-name>
application-name: <application-name>
I tried to setup a connection through WireMock to look if the call is incorrect. I tried to redirect the call. Wiremock takes the call and sends it just to the same base url written above but only with the token as a header and it works. Postman takes the same call and it works aswell.
Have a spring boot mvc app protected by spring security oauth2 using authorization code flow . App is redirecting to proper redirect uri for login when deployed and running in local machine . But in our kubernetes deployment there is a api gateway in front of the app and app is accessed at following path
https:///<k8_namespace_name>/<app_name>
where
k8_namespace_name is the kubernetes namespace name and app_name is a identifier for the app in the namespace . Issue is that redirect uri for login is going to
https:///oauth2/authorization/okta
instead of
https:///<k8_namespace_name>/<app_name>/oauth2/authorization/okta
Below is the application.yaml config
management:
endpoints:
web:
base-path: /
spring:
security:
oauth2:
client:
registration:
okta:
client-id: xxxxx
scope:
# Include the required openid scope
- openid
- employee_number
- groups_whitelist
- first_name
- last_name
- store_number
provider:
okta:
authorization-uri: https://auth.com/v1/xxxx/authorize?skip_iwa=true
token-uri: https://auth.com/v1/xxxx/token
user-info-uri: https://auth.com/v1/xxxx/userinfo
jwk-set-uri: https://auth.com/v1/xxx/keys
You can use redirect-uri property to define where user will be redirected after successful login.
It should look like that:
spring:
security:
oauth2:
client:
registration:
okta:
redirect-uri: https:///<k8_namespace_name>/<app_name>/login/oauth2/code/{registrationId}
client-id: xxxxx
scope:
# Include the required openid scope
- openid
- employee_number
- groups_whitelist
- first_name
- last_name
- store_number
provider:
okta:
authorization-uri: https://auth.com/v1/xxxx/authorize?skip_iwa=true
token-uri: https://auth.com/v1/xxxx/token
user-info-uri: https://auth.com/v1/xxxx/userinfo
jwk-set-uri: https://auth.com/v1/xxx/keys
Please remember to add your redirect uri to Okta client configuration.
I am just started with Kong API with One API
I am able to run kong api locally using its official docker image available.
And on other side I am having another Spring-Boot microservice locally running inside same Docker engine.
Problem : What configuration needs in kong api yaml file so that I can connect to my spring-boot microservice ?
My kong -api yaml file
services:
- name: control-service-integration
url: http://localhost:8080/
plugins:
- name: oneapi
config:
edgemicro_proxy: edgemicro_demo_v0
add_application_id_header: true
authentication:
apikey:
header_name: "x-api-key"
upstream_auth:
basic_auth:
username: username
password: password
routes:
- name: control-service-route
request_buffering: false
response_buffering: false
paths:
- /edgemicro-demo-v0
From kon-one api service i am getting always 502 Bad Gateway error.
Let me know if anything information required.
I found the solution for this
in above YAML
services:
- name: control-service-integration
url: http://localhost:8080/
add this value in-front of url section http://host.docker.internal:8080/ after doing lot of trials and errors finally now I am able to connect my app which is running on host.
I’m trying to access the credentials kept at a vault location through spring boot, I have roleID , secretID, nameSpace, vaultPath & address given to me.
The credentials are kept at a specific vault path.
I am trying to configure this in application.yml, but it fails, also trying to figure out where to specify the vault path.
application.yml:
spring:
application:
name: DIT
spring.cloud.vault:
authentication: APPROLE
scheme: https
uri: <uri>
namespace:
app-role:
role-id:
secret-id:
I'm adding a proxy in front of kubernetes API in order to authenticate users (among other actions) with a homemade authentication system.
I've modified my kube configuration to have kubectl hitting the proxy. The proxy has its own kubeconfig with a valid certificate-authority-data, so I don't need any credentials on my side.
So far this is working fine, here is the minimum configuration I need locally:
clusters:
- cluster:
server: http://localhost:8080
name: proxy
contexts:
- context:
cluster: proxy
name: proxy
current-context: proxy
Now the authentication should be based on a token, that I hoped I would be able to pass as part of the kubectl request header.
I tried multiple configuration, adding a user with a token in the kubeconfig such as
clusters:
- cluster:
server: http://localhost:8080
name: proxy
contexts:
- context:
cluster: proxy
user: robin
name: proxy
current-context: proxy
users:
- name: robin
user:
token: my-token
Or specifying a auth-provider such as
clusters:
- cluster:
server: http://localhost:8080
name: proxy
contexts:
- context:
cluster: proxy
user: robin
name: proxy
current-context: proxy
users:
- name: robin
user:
auth-provider:
config:
access-token: my-token
I even tried without any user, just by adding my token as part of the preferences, as all I want is to have the token in the header
clusters:
- cluster:
server: http://localhost:8080
name: proxy
contexts:
- context:
cluster: proxy
name: proxy
current-context: proxy
preferences:
token: my-token
But I was never able to see my-token as part of the request header on the proxy side. Dumping the request, all I got is:
GET /api/v1/namespaces/default/pods?limit=500 HTTP/1.1
Host: localhost:8080
Accept: application/json;as=Table;v=v1beta1;g=meta.k8s.io, application/json
Accept-Encoding: gzip
User-Agent: kubectl/v1.11.0 (darwin/amd64) kubernetes/91e7b4f
I am obviously missing something here, how can kubectl not pass the user information in its header? Let's say I do not have a proxy, how is the "kubectl -> kubernetes" token authentication working?
If someone has any experience at adding this kind of authentication layer between kubernetes and a client, I could use some help :)
Token credentials are only sent over TLS-secured connections. The server must be https://...