I have following setup given:
keycloak server at https://auth.example.com
AD connection with a LDAP provider configuration
Kerberos options set in LDAP provider configuration
authentication with any AD user works
authentication with Kerberos Tickets in browser works
As I know to use cURL with Kerberos auth it looks similar to this:
$ curl --negotiate -u : https://app.example.com/index.html
One can use Resource Owner Password Credentials Grant Type to get an Access-Token in non-interactive manner. But how do I get it using cURL with a Kerberos ticket and Keycloak?
There is an example [1] in the official documentation:
curl \
-d "client_id=myclient" \
-d "client_secret=40cc097b-2a57-4c17-b36a-8fdf3fc2d578" \
-d "username=user" \
-d "password=password" \
-d "grant_type=password" \
"http://localhost:8080/auth/realms/master/protocol/openid-connect/token"
[1] https://www.keycloak.org/docs/latest/securing_apps/index.html#_resource_owner_password_credentials_flow
[2] https://www.keycloak.org/docs/latest/server_admin/index.html#troubleshooting-2
Related
We have a Cognito user pool that supports login with email and phone number. Using Auth.verifyCurrentUserAttributeSubmit we are able to successfully verify code received on email for email change of logged in user. However the same verifyCurrentUserAttributeSubmit method returns InternalErrorException from Cognito when verifying phone_number attribute using the code received on sms. Wondering how to verify the phone_number change using Amplify?
Based on HTTP response from Cognito, something internally failed and seems to be a bug in Cognito but not sure if there is a work around. Interesting, it's able to verify email attribute.
From browser console, here is the curl equivalent snippet for the call made from Amplify in ReactJS app. The same API works fine if AttributeName being verified is email.
curl 'https://cognito-idp.ap-southeast-1.amazonaws.com/' \
-H 'authority: cognito-idp.ap-southeast-1.amazonaws.com' \
-H 'cache-control: max-age=0' \
-H 'content-type: application/x-amz-json-1.1' \
-H 'x-amz-target: AWSCognitoIdentityProviderService.VerifyUserAttribute' \
-H 'x-amz-user-agent: aws-amplify/5.0.4 js' \
--data-raw '{"AttributeName":"phone_number","Code":"713032","AccessToken":"xxxtokenxxxx"}' \
--compressed
Response:
{"__type":"InternalErrorException","message":"Internal server error."}
I am trying to configure X.509 client authentication on the Keycloak 17.0.0 (Quarkus). I am using the quay.io/keycloak/keycloak:17.0.0 to deploy it in my Kubernetes environment.
I am running the Keycloak according the https://github.com/keycloak/keycloak/blob/main/docs/guides/src/main/server/reverseproxy.adoc:
/opt/keycloak/bin/kc.sh build --spi-x509cert-lookup-provider=nginx
/opt/keycloak/bin/kc.sh start-dev --spi-x509cert-lookup-nginx-ssl-client-cert=SSL_CLIENT_CERT
And I have the configuration of the X.509 client certificate authentication in the Browser and Direct Grant authentication flows, enabled in the authentication bindings, according the https://www.keycloak.org/docs/latest/server_admin/#_x509.
So expecting that the Keycloak will take the client certificate from SSL_CLIENT_CERT header and authenticate based on that.
However, trying to use the certificate to authenticate, I receive:
{
"error_description": "X509 client certificate is missing.",
"error": "invalid_request"
}
This is my curl:
curl http://localhost:8080/auth/realms/TEST/protocol/openid-connect/token \
-H "SSL_CLIENT_CERT: <cert_content>" \
-d "grant_type=password&username=&password=&client_id=CLIENT_ID&client_secret=CLIENT_SECRET"
There is a little documentation about how to do it behind the proxy in the Keycloak Quarkus version.
Anyone able to make it work?
1.) You need to use TLS, so you can't use http protocol for that - https is required. Ideal TLS config will have proper cert setup, otherwise curl will need --insecure.
2.) -H "SSL_CLIENT_CERT: <cert_content>" \ adds HTTP header, so that's is level 7 (OSI model), but TLS connection is level 4. So this is wrong.
Curl has another parameters --cert, --key for mutual (X.509) TLS. You should to have also proper data encoding, so in theory correct curl:
curl -s -X POST \
--cert /<path>/client-pem.crt \
--key /<path>/client-pem.key \
--data-urlencode "client_id=CLIENT_ID" \
--data-urlencode "client_secret=CLIENT_SECRET" \
--data-urlencode "grant_type=password" \
--data-urlencode "username=" \
--data-urlencode "password=" \
https://<keycloak-host>/auth/realms/TEST/protocol/openid-connect/token
I have an authentication server running Keycloak, and a Apache2 webserver with mod_auth_openidc to do OAuth2 authorization.
With browsers, I can successfully intercept access to protected resource to redirect user to Keycloak login page. After successful login, user will be redirected to the resource link.
With Postman, I can also retrieve access token JWT with password grant flow, then use the access token to access protected resource. The cURL code provided by postman indicates that the mod_auth_openidc_session cookie is also required.
Next, I try to do 2-stage cURL command in Linux CLI.
First I retrieve the access token using password grant flow as below. I initiated the cookie engine to capture session cookies given by mod_auth_openidc.
# RETRIEVE ACCESS TOKEN JSON
curl -L -b ./cookie.jar -c ./cookie.jar -d 'client_id=CLIENT_ID' -d 'client_secret=368127b1-1ee0-4f3f-8429-29e9a93daf9a' -d 'username=USERNAME' -d 'password=PASSWORD' -d 'grant_type=password' 'https://AUTH_SERVER:PORT/auth/realms/REALM/protocol/openid-connect/token
# PARSE ACCESS TOKEN
access_token=`echo $response|jq '.access_token'|cut -d\" -f2`
Next, with the access token bearer in header and cookie jar file, I try to access to the protected resource.
curl -b ./cookie.jar -c ./cookie.jar --insecure -L -X GET 'https://RESOURCE_SERVER:PORT/protected_content' --header "'Authorization: Bearer "$access_token"'"
However, I still got redirected to the Keycloak login page, and the session cookie is not recorded in the cookie jar file.
Here is the recorded cookie jar file with sensitive info redacted/replaced.
# Netscape HTTP Cookie File
# https://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.
#HttpOnly_[AUTH_SERVER] FALSE /auth/realms/master/ TRUE 0 KC_RESTART eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI2Y2ZiNjYwOC1kMTlhLTQwZGUtOWJiYS04NzcxOTkzZTIwMWUifQ.eyJjaWQi[REDACTED]4aHhkVDBGZmhBZEVTSm8iLCJub25jZSI6IndTYXNYOWhGeGIxd1hKakNrS2FLMXVadVRGX3ZOZzRGVUZnMTJyYXFWbVkifX0.53645krpwlFnJ09cHAcZhNCci-DhGigu4soN5CVsZQ0
#HttpOnly_[AUTH_SERVER] FALSE /auth/realms/master/ TRUE 0 AUTH_SESSION_ID_LEGACY 6a23b139-05ba-4d22-b9e3-9ae857074814.[AUTH_SERVER]
#HttpOnly_[AUTH_SERVER] FALSE /auth/realms/master/ TRUE 0 AUTH_SESSION_ID 6a23b139-05ba-4d22-b9e3-9ae857074814.[AUTH_SERVER]
#HttpOnly_[RESOURCE_SERVER] FALSE / TRUE 0 mod_auth_openidc_state_XGEq0YKJAwSt8hxdT0FfhAdESJo NVc9Mk1FmN[REDACTED]lydKVtOw0iL-Y9iZMjzcUinutFPn74rmVvI_ERV3C8Wn1Euio8pID0jEAmu9NEfY_MEeuzOzqe6w7I20HZUNQHX0uh_vXR8
Can anyone tell me what I did wrong in the 2-stage cURL authentication/authorization process?
You have single quotes inside double quotes when setting Authorization header. This means instead of expect Authorization: Bearer token server is getting 'Authorization: Bearer token'. You can check the contents of your headers by using verbose -v option.
Following command should work as expected:
curl --header "Authorization: Bearer $access_token" -b ./cookie.jar -c ./cookie.jar --insecure -L -X GET https://RESOURCE_SERVER:PORT/protected_content'
Optionally, if you need double qoutes around token use following:
--header "Authorization: Bearer \"$access_token\""
Side note: In order not to overwrite existing cookies in cookie.jar, use different file name to store cookies from the request to authorized file.
I need to authenticate admin user via curl command so I can pragmatically add,delete, modify users in wso2
I can call the api end points for user add/mod/delete no problem. But without being able to first authenticate to wso2 it is all for naught. When I send the curl command I get no response back, and nothing shows in the logs.
This is my basic curl command, right out of the books:
curl -X POST "https://xxxxxxx.com:9443/login/portal" -H "Content-Type: application/x-form-urlencoded" -d "username=uid&password=foo&grantType=password"
You can use SCIM APIs with basic authentication to manage users.
If you want to use OAuth2 tokens, you can get them like this.
curl -k -d "grant_type=password&username=<username>&password=<password>"
-u <Consumer_key>:<Consumer_secret>
-H "Content-Type: application/x-www-form-urlencoded"
https://localhost:9443/oauth2/token
[1] https://docs.wso2.com/display/IS530/SCIM+1.1+APIs
I'm setting up this authentication through OpenLDAP:
OpenLDAP -> Pass-through (External authentication) -> SASL -> PAM -> RSA Agent
In order to access to an application via a RSA Token.
Starting from the bottom to the top:
This is my PAM configuration:
#%PAM-1.0
auth required pam_securid.so
account sufficient pam_ldap.so
account include password-auth
password sufficient pam_ldap.so
password include password-auth
This test works great:
[root#ldap ~]# testsaslauthd -u goingsolo -p 11111111
0: OK "Success."
OpenLdap is correctly configured to works with the SASL Authenticatino in PLAIN:
[root#ldap /]# ldapsearch -h localhost -b "" -LLL -s base supportedSASLMechanisms -x
dn:
supportedSASLMechanisms: PLAIN
And the userPassword of my goingsolo user is configured with {SASL}goingsolo And if I do a SASL bind it works:
[root#datap-keldap-1-n01 /]# ldapsearch -h localhost -b dc=ldap,dc=com -U "goingsolo" -w 11111111
SASL/PLAIN authentication started
0: OK "Success."
The problem is when I perform a simple bind with -D instead of -U, I receive invalid credentials:
[root#datap-keldap-1-n01 /]# ldapsearch -h localhost -b dc=ldap,dc=com -D "cn=goingsolo,ou=People,dc=ldap,dc=com" -w 11111111
ldap_bind: Invalid credentials (49)
Also when performing a sasl bind with the full dn, the authentication fails because from the /var/lag/messages:
Mar 27 19:01:00 ldap saslauthd[11777]: do_auth : auth failure: [user=cn=goingsolo,ou=People,dc=ldap,dc=com] [service=ldap] [realm=] [mech=pam] [reason=PAM auth error]
I guess this is because it does not a translate from the full dn to the simple user (goingsolo).
Any tips on what should I check?
The problem was how OpenLdap was build (I guess wrong compiling). I tryed to reinstall it and then it worked. Be sure the SASL machanism is set to plain.