My Spring Boot Application with policy enforcer works fine. But when I add via my SPI some custom claims to the authorization->permission part of the RPT token then I am always getting: Policy enforcement result for path [http://localhost:8989/customers/1] is : DENIED
I have these lines in application.properties :
keycloak.securityConstraints[0].authRoles[0]=*
keycloak.securityConstraints[0].securityCollections[0].patterns[0]=/*
keycloak.policy-enforcer-config.enforcement-mode=enforcing
keycloak.policy-enforcer-config.paths[0].path=/customers/*
keycloak.policy-enforcer-config.paths[0].methods[0].method=GET
keycloak.policy-enforcer-config.paths[0].methods[0].scopes[0]=view
My RPT token looks like:
"authorization": {
"permissions": [
{
"scopes": [
"view"
],
"claims": {
"customers:view:country": [
"[Belgium]"
]
},
"rsid": "fe8b4cd1-601b-46cf-9f2b-1534ade8cab2",
"rsname": "customers"
}
]
},
When the "claims" part is added access is denied.
Any idea why it is always denied?
The policy enforcer should actually ignore those additions, right?
It should evaluate access based on resource and scope in the RPT token.
Is there a way to disable this additional claims check?
Related
I'm trying to have my Flutter app log to a specific google cloud project's log bucket instead of the developer console. I'm running into a Permission 'logging.logEntries.create' denied on resource (or it may not exist). when I run the code. How can I fix this? The dart code for posting the log is below.
final logEntry = {
"jsonPayload": {
"message": {
"test": "entry",
"test 2": "entry 2",
},
},
"logName": logName,
"resource": {
"type": "global",
"labels": {
"project_id": projectId,
},
}
};
final url = "https://logging.googleapis.com/v2/entries:write";
http.Response response = await http.post(
Uri.parse(url),
headers: {
HttpHeaders.contentTypeHeader: 'application/json',
"X-goog-api-key": apiKey,
},
body: json.encode(
{
"entries": [logEntry],
},
),
);
The API key I created has no API restrictions, but I did also try restricting it to only use the logging API, but it still has the same error.
You need to give the logging.logEntries.create permission to the Service Account used by your Flutter app.
From the IAM page in Google Cloud console, you will be able to give a role containing the above permission to your Service Account.
If you used a custom role, you can also add directly the logging.logEntries.create permission to this custom role.
As mentioned in the document:
The permission logging.logEntries.create is needed on each project,
organization, billing account, or folder that is receiving new log
entries, whether the resource is specified in logName or in an
individual log entry.
So, you need to give the logging.logEntries.create permission to the Service Account used by your Flutter app.
You can also refer the detailed article on Access control guide.
My users has a birthDate attribute:
I created a mapper in client:
Yet it can't be seen in access token:
{
"exp": 1646589516,
"iat": 1646589216,
"jti": "7cee1468-8d80-4f14-a118-b07477c1e1e7",
"iss": "http://localhost:8080/realms/...",
"aud": "account",
"sub": "f:fd2a5a5a-c7a0-4e74-81a8-916a85885f98:...",
"typ": "Bearer",
"azp": "...",
"session_state": "efce7a63-2a8f-438d-b4a1-f5d979a00c81",
"acr": "1",
"realm_access": {
"roles": [
"offline_access",
"uma_authorization"
]
},
"resource_access": {
"account": {
"roles": [
"manage-account",
"manage-account-links",
"view-profile"
]
}
},
"scope": "openid profile email",
"sid": "efce7a63-2a8f-438d-b4a1-f5d979a00c81",
"email_verified": false,
"preferred_username": "..."
}
Can it happen that the keycloak caching somewhere? (I cleared the caches at Realm --> Caches)
I am desperate... Every tutorial does this and it is not working for me.
Update: I could test it on a server that is remote and it is working. Where the hell the keycloak is caching and screwing me?
---------------------------------------------------------------------------
Update2: deleted the keycloak & reinstalled so start from 0:
created realm: ep
created client: ep
Here we can see the user has an attribute birthDate with value my-custom-birth-date:
I go Clients --> ep client --> Mappers and create a mapper like this:
Clients --> ep --> Client Scopes --> Evaluate --> Evaluate button we can see that the birthDate can be found there (last row, also the default birthdate can be seen):
If I evaluate on the user P...o then you can see the access token does not contains the birthDate attribute:
If I use postman to request a token for this user, the access_token looks like this:
Still missing the attribute birthDate.
I repeated every action I did above and in the remote keycloak the attribute can be seen (the last one on the image):
---------------------------------------------------------------------------
So I found the problem:
Here is my keycloak folder and the path to it:
I copied the data folder to here thinking I won't need to recreate the realm/client/etc:
Whenever I reinstalled the keycloak, I deleted the keycloak-17.0.0 folder and reinstalled to the same place:
After I deleted both data and keycloak-17.0.0 and recreate the realm/client/mappers/etc, it is working perfectly...
No idea why did the keycloak checked for configurations/settings/caches a folder above in the tree...
I know we have an option to see what capabilities we have for a specific path for a given token
Example - using the command - vault token capabilities secret/foo
But is there a way to identify what are all the paths I can access for the given token with read or write or update like any capability.
I tried by vault token lookup to find the policy attached to my token. But I'm not able to read that policy to see what paths I have access.
vault token create -policy=read-policy -no-default-policy
Key Value
--- -----
token XXXXXXXXXXXXXXXXXXXXXXXX
token_accessor R3uPmiu30Hw8HgSbFcS3wkDJ
token_duration 768h
token_renewable true
token_policies ["read-policy"] ++++++++++++++++++++++++++++++++++++++++
identity_policies []
policies ["read-policy"]
After login using the token, if I try to read that policy
vault policy read read-policy
Error reading policy named read-policy: Error making API request.
URL: GET http://127.0.0.1:8200/v1/sys/policies/acl/read-policy
Code: 403. Errors:
* 1 error occurred:
* permission denied
So Do we have to include read capability for sys/policies/acl/read-policy in the creation of read policy hcl file?(Even i tried this but capabilities are denied in this path. seems only root can read)
or as per vault design, we cannot see what paths we have access? unless otherwise vault admin says? Or de we have any commands to get that information?
Correct me if I'm wrong
Further dig more into vault,i found the solution for this.We have to run the below command which will give us what paths we have what capabilities
vault read sys/internal/ui/resultant-acl --format=json|jq -r .data
{
"exact_paths": {
"auth/token/lookup-self": {
"capabilities": [
"read"
]
},
"sys/internal/ui/resultant-acl": {
"capabilities": [
"read"
]
},
"sys/mounts": {
"capabilities": [
"list"
]
}
},
"glob_paths": {
"sys/mounts/": {
"capabilities": [
"create",
"delete",
"list",
"read",
"sudo",
"update"
]
}
},
"root": false
}
So if we want our token users to know what path/capabilities they have then when we create policy we have to include the read capability to path sys/internal/ui/resultant-acl. Example i have created this policy for just managing secrets engine and i have included that capability, so that the user who is going to use the token which mapped to the policy can read what path/capability he or she have
cat /tmp/secrets-mgmt.hcl
path "sys/mounts/*" {
capabilities = ["create","read","update","delete","list","sudo"]
}
path "sys/mounts" {
capabilities = ["list"]
}
# Allow tokens to look up their own properties
path "auth/token/lookup-self" {
capabilities = ["read"]
}
# based on how the internal ACL features and capabilities change.
path "sys/internal/ui/resultant-acl" {
capabilities = ["read"]
}
I am trying to assign a policy to my ldap group/user so that a user can access the auth methods but it doesn't seem to be working. Here is my situation.
I have a policy name - test-ldap-group with capabilities :
path "auth/*" {
capabilities = ["create", "read", "update", "delete", "list"]
}
path "kv/*" {
capabilities = [ "read", "list" ]
}
Now I have assigned this policy to my ldap group : test-group. The 2nd one with "kv/* is working fine because I can see the secrets on deployed on kv engine but the 1st one where I am trying to assign the auth method it just gives me the error -
Not authorized
Ember Data Request GET /v1/identity/entity/id?list=true returned a 403 Payload (application/json) [object Object]
1 error occurred: * permission denied
Also this works - (this gives access to everything under kv/ which we don't want)
path "kv/*" {
capabilities = [ "read", "list" ]
}
BUT this doesn't work
path "kv/staging/db" {
capabilities = [ "read", "list" ]
}
What could be i am doing wrong here?
Vault Version - Vault v1.5.3
kv version - 1
The endpoint that is failing for you is this endpoint for listing identities. It may be the case that when you are calling this command, your user or VAULT_TOKEN don't have the required permissions to list entities. You can try to log into Vault as the root user or use the root VAULT_TOKEN if you are executing the commands via cURL, for example.
I'm looking for help of somebody who knows something about Jira add-ons.
I'm trying to implement Jira add-on with an ability to create issues on behalf of a user.
So, I completed all steps (as I think) leading me to my goal, but I faced a problem with impersonating. When I try to create an issue using Jira REST API, I receive the following error:
{
"error": "Add-on 'com.example.myapp' disallowed to impersonate the user because 'no valid active user exists'"
}
What was done:
Folowing the getting started tutorial I created the add-on descriptor:
{
"name": "Hello World",
"description": "Atlassian Connect app",
"key": "com.example.myapp",
"baseUrl": "https://url.ngrok.io",
"vendor": {
"name": "Example, Inc.",
"url": "http://example.com"
},
"authentication": {
"type": "jwt"
},
"scopes": [
"act_as_user",
"read",
"write",
],
"lifecycle": {
"installed": "/api/created",
},
"apiVersion": 1
}
I also implemented webhook to handle 'installed' callback from add-on like described here. So, when a user installs the add-on the webhook will receive the following object:
{
'key': 'com.example.myapp',
'clientKey': '<client key>',
'oauthClientId': '<OAuth client ID>',
'publicKey': '<public key>',
'sharedSecret': '<shared secret>',
'serverVersion': '100095',
'pluginsVersion': '1.250.0',
'baseUrl': 'https://<user's domain>.atlassian.net',
'productType': 'jira',
'description': 'Description',
'eventType': 'installed'
}
Using this data I generated JWT signed with the shared secret like described in the tutorial. So, my JWT payload includes the following claims:
{
'iss': 'urn:atlassian:connect:clientid:<OAuth client ID>',
'sub': 'urn:atlassian:connect:useraccountid:<client key>',
'tnt': 'https://<user's domain>.atlassian.net',
'iss': '<created at>',
'exp': '<created at + 1 minute>'
}
The next step I performed is access token generation using auth.atlassian.io/oauth2/token endpoint and the following parameters:
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&assertion=<my JWT>&scope=ACT_AS_USER READ WRITE
The result of all these actions is an access token witch I can use to perform REST API requests. But the error described above returned every time I try to create Jira issue performing POST [user's domain].atlassian.net/rest/api/2/issue/ with Authorization: Bearer [access_token] header.
What I've noticed is that account ID in installed callback object (clientKey) has 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' (uuid) format. But when I open my account in Jira (account in witch the add-on is installed) I see that the account ID in URL has 'YYYYYY:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' format. I prepended the subject in my JWT payload with YYYYYY part:
'sub': 'urn:atlassian:connect:useraccountid:'YYYYYY:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
and generated a new access token using this JWT. I've used new access token to create an issue and it was successfully created, the reporter of the issue is a user installed my add-on, just like I wished.
Finally, the question is: where can I find that YYYYYY part for my add-on? How to get it automatically? What I've missed following the tutorials? Any help will be appreciated.
Thank you!