Vault version 1.5.2
My end goal is to use Vault in some Terraform code to retrieve temporary credentials. The issue is Terraform will always generate a new child token even if the current token is a 5 minute token. This means the current VAULT_TOKEN must be some sort of super root token because I've tried logging in with the LDAP backend and it doesn't matter which policies or token roles I try to use it seems I can't ever generate new tokens.
To replicate what Terraform is doing:
vault login -address vault.example -ca-cert ca.pem -method ldap -path ldap_users user=botman
Couldn't start vault with IPC_LOCK. Disabling IPC_LOCK, please use --privileged or --cap-add IPC_LOCK
Password (will be hidden):
s.<token>
I have all of the permission as defined by the policies and everything seems fine.
Now try to create a child token:
vault token create -address vault.example -ca-cert ca.pem -role superrole
Error creating token: Error making API request.
URL: POST https://vault.example/v1/auth/token/create/superrole
Code: 400. Errors:
* restricted use token cannot generate child tokens
Remove the -role parameter and we get the same error.
I've tried looking everywhere to see what I'm missing, but the only token that can create child tokens seems to be the root token.
I apologize if I missed something very simple.
An example policy that I have attached (I've tried many polices but this one seems the most extreme)
path "auth/*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
Any help is appreciated.
EDIT:
I took the time to setup some approles to test this out. I added the exact same policies as the LDAP backend. With the approle I can get a token and then create new tokens from the initial token. I took a look at the LDAP documentation to see if I missed somewhere that says you can't create child tokens from tokens originating from LDAP and I couldn't find anything: https://www.vaultproject.io/docs/auth/ldap.html
EDIT2:
Pulumi config for the LDAP Auth Backend
return vault.ldap.AuthBackend(
resource_name="vault-ldap-{}".format(ldap.name),
binddn=bind_dn,
bindpass=bind_pass,
certificate=cert,
description=ldap.desc,
discoverdn=False,
groupattr="cn",
groupdn=ldap.groupdn,
groupfilter="(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))",
insecure_tls=False,
path="ldap_{}".format(ldap.name),
starttls=False,
tls_max_version="tls12",
tls_min_version="tls10",
token_explicit_max_ttl=14 * 60 * 60 * 24,
token_max_ttl=7 * 60 * 60 * 24,
token_num_uses=56,
url=url,
userattr="samaccountname",
userdn=ldap.userdn,
opts=opts,
)
I see your LDAP backend is setting token_num_uses. From this documentation and this discussion, having token_num_uses set to something non-zero will prevent the token from creating child tokens.
The reason it is broken for LDAP and working for AppRole is because the LDAP backend is applying the token_num_uses property, whereas I'm guessing the AppRole backend is not.
Related
I am using keycloak operator to install keycloak and i have configured keycloak to use external database (RDS instance). ==> (externalDatabase: true)
The keycloak instances are up and running without any issues.
When i tried to login to the keycloak UI with master realm credentials it is telling that the credentials are invalid, though the credentials are correct.
I am getting the credentials using the following command.
kubectl get secret credential-test -o go-template='{{range $k,$v := .data}}{{printf "%s: " $k}}{{if not $v}}{{$v}}{{else}}{{$v | base64decode}}{{end}}{{"\n"}}{{end}}'
The following is the log from the instance.
07:40:48,172 WARN [org.keycloak.events] (default task-1) type=LOGIN_ERROR, realmId=master, clientId=security-admin-console, userId=566f4e3e-c0f1-4304-bca2-686321d88b87, ipAddress=10.242.3.61, error=invalid_user_credentials, auth_method=openid-connect, auth_type=code, redirect_uri=https://test123.net/auth/admin/master/console/, code_id=5561bc9e-e2b9-41e3-836d-37add6e74c1c, username=admin, authSessionParentId=5561bc9e-e2b9-41e3-836d-37add6e74c1c, authSessionTabId=Oq-orhggRE4
Any advice or suggestion is highly appreciated.
I had this, or a similar issue as well when setting up the operator.
It appears that the external database that supposedly stores the admin username and password isn't updated when a new secret is generated if, say, the CRD for the Keycloak instance is deleted along with the secret. The steps I went through to fix it was to:
Delete the CRD.
Delete the database.
Recreate the database.
Recreate the CRD.
That way, the database should have no reason to accept the new credentials.
There is probably a better solution. But I could not find it in the docs so far.
I've just started with the oauth2 and xero (using .net)
I've run through the scoop install, following the docs, grant type of 'authorization_code', scope of 'd', which gave me the access and refresh tokens.
Now when running the example project, XeroNetStandardApp, after replacing client id, secret, callback uri and tokens, I'm getting a 401 when I try to do anything after retrieving the new token.
The token refresh appears to be working fine. If I call https://api.xero.com/connections with the bearer, I get [] (so, no elements in the response), so I assume this is some type of user auth error, but I'm at a bit of a loss as to what I do here.
Any help would be much appreciated
When setting up xoauth via powershell, explicitly set the scopes you are wanting the user to have. This seems obvious to me now, but didn't while I was following the setup instructions
I'm working on a gcloud service which is not publicly available, i.e. you need to connect to it with your Authorization Header set with your gcloud identity token.
The docs used curl to show how to use it from the command line, however as my case concerns a web application I used a browser extension to inject this header when connecting to pages.
Silly me, I forgot to turn if off after I was done, which resulted in accessing a few websites with that token set in the request header. This means some third parties may now have that code.
2 questions concerning this:
How bad is this? What can this token be used for by the ill-willed?
How can I reset/revoke/renew this token?
Identity Tokens are JWTs and are bearer tokens (as you are undoubtedly aware) and generally include a short-ish (60 minute) expiry.
As you suggest, you should be very careful with them as they could be used unscrupulously (while valid).
You may query your JWT using a (trustworthy!) tool to check the expiry:
E.g https://jwt.io/
I'm unsure (doesn't mean that there isn't) whether there's a way to forcibly expire Google-issued JWTs
Update:
Spoke with a Googler who's very well informed on auth and he confirmed that you must await expiry.
Update:
Independently, I reminded myself that Google has a( very trustworthy) endpoint to verify tokens too (I can just never remember the URL, but) it's:
TOKEN=$(gcloud auth print-identity-token)
curl \
--request GET \
https://oauth2.googleapis.com/tokeninfo?id_token=${TOKEN}
And, for completeness, for access tokens:
TOKEN=$(gcloud auth print-access-token)
curl \
--request GET \
https://oauth2.googleapis.com/tokeninfo?access_token=${TOKEN}
Our Vault is configured to use github tokens. How can one use spring-cloud-vault and use github tokens? looked all over documentation and forums.
Thanks in advance.
Assuming "spring-cloud-vault" is the same as Hashicorp Vault (and according to https://cloud.spring.io/spring-cloud-vault/reference/html/ this looks pretty much the same!), you first need make sure the "github" auth method is enabled.
Our Vault is configured to use github tokens
So this seems to be the case already.
Next you need to create a GitHub personal token on https://github.com/settings/tokens. Click on "Generate new token" and in the "admin:org" scope, select "read:org", then generate the token and copy it.
See this GitHub guide for additional help: https://help.github.com/en/articles/creating-a-personal-access-token-for-the-command-line
You will get a token code. With this you can log in to your Vault. In the Vault UI select "GitHub" as Method, then paste the copied token.
If you are using the Vault API, e.g. with curl, you need to add the token as a HTTP header:
$ curl -X POST \
--data '{"token": "YOURSECRETANDPERSONALGITHUBTOKEN" }' https://vault.example.com/v1/auth/github/login
Note that in this example Vault is behind a reverse proxy, therefore not using the port 8200 in the URL.
You should get a HTTP 200 and a json reponse when you successfully logged in.
See https://www.vaultproject.io/docs/auth/github.html for more details.
Is AEM Authentication (closed user group) stateless ? What happens if we have multiple publisher, will the authentication handler ensure the user is authenticated in all the instance of the publisher ?
Could not find a document confirming this, So any help is appreciated.
Thanks.
The default AEM Authentication (CRX Login Module) is not stateless , the authentication is confirmed by a login token. When a user logs in the token information is stored under .tokens node of the corresponding user node (/home/users). The value of the token is also stored in the browser as a cookie login-token. Whenever a request comes in , the cookie value and the token in the repository is compared.[
You can test by deleting the .tokens node and refreshing some page that cannot be accessed by anonymous
]
In a multi publisher environment the token is created only on the instance which logged the user in. Since other instances cannot find the token for the cookie value in their repositories the request will be rejected.
If you enable sticky sessions , all requests by a particular client are always directed to the same instance.
Here's a page on Oak's token module . AEM uses crx token module but how they work is essentially same. Since your credentials are passed to a single instance by a form based authentication handler the token is created only in one instance. The authentication handler page also has some details on the token and the cookie.
UPDATE:
With AEM 6.1 , the authentication can now be made stateless as long as the user exists on all the publish instances. This is done by using a encrypted cookie that can be decrypted by all publish instances when they share the same HMAC key. More information can be found here : https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html
i think it´s possible if you activate the clustering on your authors, the .token node will be replicated to all instances and while comparing the users token ressource and the cookie the identification succeeds, this is one of the benefits of the jcr philosophy :all is content
Enable encapsulated token option in OSGI. Then it will authenticate seamlessly. But there are 2 prerequisite or conditions to get it worked. One is to put the same HMAC key on all the instances and secondly the user should exist. if these 2 conditions are met then if you login on one stack and the second stack wont required authentication again.