in WSO2IS 5.7 I used to utilize a custom JWT token issuer by deploying its jar file into wso2is_home/repository/components/lib, then changing the OAuth section in identity.xml file at the IdentityOAuthTokenGenerator element with my custom token issuer's class:
<OAuth>
...
<!--<IdentityOAuthTokenGenerator>org.wso2.carbon.identity.oauth2.token.JWTTokenIssuer</IdentityOAuthTokenGenerator>-->
<IdentityOAuthTokenGenerator>it.smartcity.wso2.jwt_generator.CustomTokenIssuer</IdentityOAuthTokenGenerator>
...
</OAuth>
restarting the server. Then I was able to see it in the Service Provider configuration:
With WSO2IS 5.10, besides putting the jar in the components/lib folder, I edited only the deployment.toml file, adding the following:
[oauth.extensions]
token_generator = "it.smartcity.wso2.jwt_generator.CustomTokenIssuer"
as described here https://is.docs.wso2.com/en/latest/learn/extension-points-for-oauth/#oauth-token-generator but it just doesn't work.
I can't see my token issuer in the Service Provider screen.
Is there anything else I should do?
You can add custom token issuers in the following way in 5.10.0 instead of token_generator.
[[oauth.extensions.token_types]]
name = "CustomTokenIssuer"
issuer = "it.smartcity.wso2.jwt_generator.CustomTokenIssuer"
persist_access_token_alias = true
Ref: https://github.com/wso2/docs-is/issues/1140
Related
Below is my kubeconfig file for accessing kubernetes clusters:
kind: ClientConfig
apiVersion: authentication.gke.io/v2alpha1
spec:
name: dev-corp
server: https://10.x.x.x:443
certificateAuthorityData: ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
authentication:
- name: oidc
oidc:
clientID: aaaaad3-9aa1-33c8-dd0-ddddd6b5bf5
clientSecret: ccccccccccccccccc-
issuerURI: https://login.microsoftonline.com/aaaa92-aab7-bbfa-cccf-ddaaaaaaaa/v2.0
kubectlRedirectURI: http://localhost:12345/callback
cloudConsoleRedirectURI: http://console.cloud.google.com/kubernetes/oidc
scopes: offline_access,profile
userClaim: upn
userPrefix: '-'
groupsClaim: groups
preferredAuthentication: oidc
There are different OAuth grant types.
My understanding is, above OAuth grant type is client credential grant type, that requires client_id, client_secret, token URL(issuerURI), scope
What is the significance of fields kubectlRedirectURI, cloudConsoleRedirectURI, userClaim, userPrefix?
How OIDC different from OAuth2?
oauth2.Config does not store userClaim & userPrefix, groupsClaim information
, as shown here.... https://github.com/golang/oauth2/blob/master/oauth2.go#L41
How to store kind:ClientConfig with oidc based authentication into cache? for example api.Config can be stored with an API from client-go to write api.Config as shown here.
KUBECTL_REDIRECT_URL: the redirect URL that kubectl oidc login uses for authorization. This is typically of the format http://localhost:PORT/callback, where PORT is any port above 1024 that will be available on developer workstations, for example http://localhost:10000/callback. You must register the URL with your OIDC provider as an authorized redirect URL for the client application.
USER_PREFIX: prefix prepended to user claims to prevent conflicts with existing names. By default, an issuer prefix is appended to the userID given to the Kubernetes API server (unless the user claim is email). The resulting user identifier is ISSUER_URI#USER. We recommend using a prefix, but you can disable the prefix by setting USER_PREFIX to -.
userClaim: the user identifier in the token under the claim name configured in spec.authentication.oidc.userClaim in the client configuration file.
cloudConsoleRedirectURI the name tell the story, the cloud redirect URL for OIDC, for example in case of google https://console.cloud.google.com/kubernetes/oidc
OIDC vs OAuth2
What's the difference between OpenID and OAuth?
The file in the question from OIDC and you are comparing the value with Oauth, both handling at different way, better to update the question again with Oauth config file.
api-server-authentication
you can check kubeconfig builder
kubernetes-engine-oidc
How to store kind:ClientConfig with oidc based authentication into cache?
you can write to a file and then read, or somewhere in the cloud storage as well
How Mastodon configure login using SSO, such as openid with keycloak? I search in Github and configure Mastodon follow this guide, but it doesn't work.
This is my environment variable:
OIDC_ENABLED=true
OIDC_DISPLAY_NAME=SSO
OIDC_AUTH_ENDPOINT=https://SSO_URL/realms/mastodon/.well-known/openid-configuration
OIDC_ISSUER=https://SSO_URL/realms/mastodon
OIDC_DISCOVERY=true
OIDC_SCOPE="openid,profile"
OIDC_UID_FIELD=uid
OIDC_CLIENT_ID=masto
OIDC_REDIRECT_URI=https://MASTODON_URL/auth/auth/openid_connect/callback
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
OIDC_CLIENT_SECRET=***
I checked the error log via this command but it is empty.
docker-compose logs | grep ERROR
Even the text of the SSO button has not changed.
There is the screenshot of sso button
my config:
OIDC_ENABLED=true
OIDC_DISPLAY_NAME=My IDM
OIDC_DISCOVERY=true
OIDC_ISSUER=https://<keycloak_url>/auth/realms/<real>
OIDC_AUTH_ENDPOINT=https://<keycloak_url>/auth/realms/<real>/.well-known/openid-configuration
OIDC_SCOPE=openid,profile,email
OIDC_UID_FIELD=preferred_username
OIDC_CLIENT_ID=<client id>
OIDC_CLIENT_SECRET=<client secret>
OIDC_REDIRECT_URI=https://<mastodon URL>/auth/auth/openid_connect/callback
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
Tested with Mastondo 3.5.3 and Keycloak 7.0.1
Maybe, only change yours OIDC_SCOPE and OIDC_UID_FIELD environments values.
I cannot comment but Erik suggestion was really good, here is our minimal configuration using Keycloak in discovery mode:
# Enable OIDC
OIDC_ENABLED=true
# Name your button (ignored in current 3.5.3 but fix is done in upcoming releases)
OIDC_DISPLAY_NAME=Login with MySSO
# Where to find your Keycloak OIDC server
OIDC_ISSUER=https://<keycloak_domain>/realms/<my_realm>
# Use discovery to determing all OIDC endpoints
OIDC_DISCOVERY=true
# Scope you want to obtain from OIDC server
OIDC_SCOPE=openid,profile,email
# Field to be used for populating user's #alias
OIDC_UID_FIELD=preferred_username
# Client ID of the client you configured for Mastodon in Keycloak
OIDC_CLIENT_ID=<keycloak_client_id>
# Client secret of the client you configured for Mastodon in Keycloak (in production, use secrets Docker secrets in our case)
OIDC_CLIENT_SECRET=<keycloak_client_secret>
# Where OIDC server should come back after authentication
OIDC_REDIRECT_URI=https://<mastodon_domain>/auth/auth/openid_connect/callback
# Assume emails are verified by the OIDC server
OIDC_SECURITY_ASSUME_EMAIL_IS_VERIFIED=true
So only difference is that we didn't have to add the OIDC_AUTH_ENDPOINT thanks to OIDC discovery.
I am getting success and responder status information too from ADFS, I checked for both of cases by turning on and off validate signature switch, setting PROXY_ADDRESS_FORWARDING=true and also to porto HTTP and https forwarding.
No one solution from above given worked well for me.
• You can try the settings in keycloak to be configured as below for it to act as a service provider to ADFS IdP so that you will be able to get the SAML requests to process correctly: -
‘ IdP URL: ${IDP_URL}/adfs/ls/
NameID Policy Format: persistent
WantAuthnRequestsSigned: true
WantAssertionsSigned: true
SignatureAlgorithm: RSA_SHA256
SAMLSignatureKeyName: CERT_SUBJECT ‘
Thus, when you configure the above settings in keycloak, also ensure that you update NameID policy in keycloak as SP and similarly custom settings on the IdP side as well to ensure NameID is sent back as ‘persistent’ in format.
Had the same error message with a misconfigured identity provider on Keycloak 15.
Try this:
Go to https://[ADFS server hostname]/federationmetadata/2007-06/federationmetadata.xml to download the ADFS server metadata
Find the X509Certificate fields marked 'signing' in the metadata
Go to your Keycloak Identity Provider definition -> settings -> 'Validating X509 Certificates' and insert the values from the metadata. Alternatively you can import the metadata file using Keycloak's import button when you create a new identity provider. Note: if the metadata contains multiple certificate values you can comma delimit them when you enter them in your keycloak identity provider definition.
i am new to grafana and i want to use a JWT authentication as described in grafana docs : https://grafana.com/docs/grafana/latest/auth/jwt/ how can i use generally the JWK to authenticate with external Identity provider ?
specifically, which jwts endpoint i have to use, is it my main base url for my provider? and then the provided http auth header?
my grafana.ini configuration file :
[auth.jwt]
enabled = true
header_name = X-JWT-HEADER
cache_ttl = 60m
jwk_set_url = https://$AUTH-PROVIDER-URL/
username_claim = user
email_claim = email
after restarting the grafana server i see no changes for my grafana login page and i can still login only with the admin user. should this works with such configuration or I have missed something?
Note that the auth.jwt is currently broken by design:
https://github.com/grafana/grafana/issues/8198
Even if you get everything else right it requires you to have prepopulated all accounts in grafana. It should provide similar functionality to auto-sign-up provided in auth.proxy The whole argument for auth.jwt is to provide something similar to, but safer to auth.proxy:
https://cloud.google.com/iap/docs/identity-howto
#Ying.Zhao
the authentication with JWT didn't work due to missing some claim properties in the json web endpoint (JWKs url)..
alternatively you can use the "auth generic" or proxy-auth for your OAuth Login.
[auth.proxy]
enabled = true
# HTTP Header name that will contain the username or email
header_name = X_HEADER_NAME
header_property = username
Adding the match-claims to the configuration file doesn't seem to do anything. Actually, Gatekeeper is always throwing me the same error when opening a resource (with or without the property).
My Keycloak server is inside a docker container, accessible from an internal network as http://keycloak:8080 while accessible from the external network as http://localhost:8085.
I have Gatekeeper connecting to the Keycloak server in an internal network. The request comes from the external one, therefore, the discovery-url will not match the 'iss' token claim.
Gatekeeper is trying to use the discovery-url as 'iss' claim. To override this, I'm adding the match-claims property as follows:
discovery-url: http://keycloak:8080/auth/realms/myRealm
match-claims:
iss: http://localhost:8085/auth/realms/myRealm
The logs look like:
On startup
keycloak-gatekeeper_1 | 1.5749342705316222e+09 info token must contain
{"claim": "iss", "value": "http://localhost:8085/auth/realms/myRealm"}
keycloak-gatekeeper_1 | 1.5749342705318246e+09 info keycloak proxy service starting
{"interface": ":3000"}
On request
keycloak-gatekeeper_1 | 1.5749328645243566e+09 error access token failed verification
{ "client_ip": "172.22.0.1:38128",
"error": "oidc: JWT claims invalid: invalid claim value: 'iss'.
expected=http://keycloak:8080/auth/realms/myRealm,
found=http://localhost:8085/auth/realms/myRealm."}
This ends up in a 403 Forbidden response.
I've tried it on Keycloak-Gatekeeper 8.0.0 and 5.0.0, both with the same issue.
Is this supposed to work the way I'm trying to use it?
If not, what I'm missing?, how can I validate the iss or bypass this validation? (preferably the former)?
It is failing during discovery data validation - your setup violates OIDC specification:
The issuer value returned MUST be identical to the Issuer URL that was directly used to retrieve the configuration information. This MUST also be identical to the iss Claim value in ID Tokens issued from this Issuer.
It is MUST, so you can't disable it (unless you want to hack source code - it should be in coreos/go-oidc library). Configure your infrastructure setup properly (e.g. use the same DNS name for Keycloak in internal/external network, content rewrite for internal network requests, ...) and you will be fine.
Change the DNS name to host.docker.internal
token endpoint: http://host.docker.internal/auth/realms/example-realm/open-id-connect/token
issuer URL in your property file as http://host.docker.internal/auth/realms/example-realm
In this way both outside world access and internal calls to keycloak can be achieved