I am using KeyCloak REST APIs and created a GROUP and a ROLE. Using REST API how to assign the ROLE to the Group?
Here is the relevant APIs -
KeyClaok API Guide
POST /admin/realms/{realm}/groups/{id}/role-mappings/realm
So question is how to use this API? Should I at first create the ROLE or this API itself will create the ROLE and do the mapping?
I tried in both the ways -
Create the ROLE by POST, retrieve the RoleId from the response and send another POST to /admin/realms/{realm}/groups/{id}/role-mappings/realm by re-sending the same RoleRepresentation object with the created Id. Also I passed the GroupId with whom I want to map the Role. But I am getting error.
In this case I didn't create the Role at the very beginning, but sent the RoleRepresentation object in the /admin/realms/{realm}/groups/{id}/role-mappings/realm API call. Again I am getting error.
The API guide is not clear on how to map the Group with the Role.
Any help will be highly appreciated.
Request is good. For example I have this one:
http://localhost:5440/auth/admin/realms/{yourRealm}/groups/8129e7ed-db5f-423b-91f5-779b9d448d3b/role-mappings/realm
But you have to create the role first and send this RoleRepresentation in your BodyParameter. There is an array of RoleRepresentation.
For example my array of RoleRepresentation with one role:
[{"id":"16f77b0f-a03e-4995-a09f-dc02a0ee3f03","name":"rolle2","scopeParamRequired":false,"composite":false,"clientRole":false,"containerId":"yourRealm"}]
Related
I am aware of this question especially this answer.
According to the documentation calling GET /{realm}/users gets you a UserRepresentation, which lists clientRoles as optional. That suggests, that it should be available in principle. But I do not know how I can leverage this.
I defined the endpoint as
const usersEndpoint = `${adminEndpoint}/realms/${realm}/users`;
Which should be correct.
Or am I reading something wrong?
I was thinking about it the wrong way. You are able to get a list of users having a role or a group by:
GET /{realm}/clients/{id}/roles/{role-name}/users
resp.
GET /{realm}/groups/{id}/members.
In order to get the list of every user having which roles, you could iterate over all roles and request their repective users and merge it.
Or in my way, retrieving the list of users having a discrete role was enough to achieve what I wanted.
I am trying to retrieve users list based on their roles. I have this role: ROLE_ADMIN. I would like to retrieve every user that have this role.
I try it with this endpoint:
http://10.10.10.10:5555/auth/demo-realm/clients/e286a05c-6641-49c3-bb7c-ffe5dd2d8c66/roles/ROLE_ADMIN/users
but it sends me back this:
{
"error": "RESTEASY003210: Could not find resource for full path: http://10.10.10.10:5555/auth/demo-realm/clients/e286a05c-6641-49c3-bb7c-ffe5dd2d8c66/roles/ROLE_ADMIN/users"
}
I found the endpoint here: https://www.keycloak.org/docs-api/11.0/rest-api/index.html under "Return List of Users that have the specified role name".
I can reach these end points for example:
http://10.10.10.10:5555/auth/realms/demo-realm/protocol/openid-connect/token
http://10.10.10.10:5555/auth/admin/realms/demo-realm/users
What did I miss? What makes this to not work?
Thanks in advance.
To get the users associate with a given Realm role you need to call the endpoint:
GET <KEYCLOAK_HOST>/auth/admin/realms/<YOUR_REALM>/roles/<ROLE_NAME>/users
to get the users associate with a given Client role you need to call this endpoint:
GET <KEYCLOAK_HOST>/auth/admin/realms/<YOUR_REALM>/clients/<CLIENT_ID>/roles/<ROLE_NAME>/users
where <CLIENT_ID> is the ID from the client to which the <ROLE_NAME> belongs to.
Finally, to get the client ID, you can call this endpoint:
GET <KEYCLOAK_HOST>/auth/admin/realms/<YOUR_REALM>/clients?clientId=<ID_OF_CLIENT>
Note that the client ID is the unique ID generated by Keycloak, whereas <ID_OF_CLIENT> is the Client ID that you have given to your Keycloak client.
I am using this call https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleAssignments?api-version=2015-07-01 to get role assignment of subscription. The output is of this gives principalId and other values
Question is How can I differentiate the principalId is user principal or serviceprincipal?
This is needed to for me to query graph api to get appid (if service principle) or display name , upn ( if user principle).
Graph APi has 2 different call for this hence while automating I need to know which one to be called based on object type.
User: https://graph.windows.net/microsoft.com/users/principalid?api-version=1.6
Service Pricipal: https://graph.windows.net/microsoft.com/servicePrincipals/principalid?api-version=1.6
Graph APi has 2 different call for this hence while automating I need to know which one to be called based on object type.
Based on my understanding, you could use the Objects - Get Objects By Object Ids Rest API to get the objects by principleid, no need to call 2 different calls. You also could get the object type from the response.
POST https://graph.windows.net/{tenantID}/getObjectsByObjectIds?api-version=1.6
I test with 2 principalids, one is the service principal and another is user.
Test Result:
I am trying to limit a SAP user´s access to transaction SOST. He may only have read/display permissions. I have tried to limit the authorizations in a role using the authorization objects S_TCODE, S_DATASET, S_OC_ROLE and S_OC_SEND. But it is not sufficient.
Any ideas?
You can check at SU24 the objects related to SOST TCode. I think this ones may be the ones you're looking for:
S_OC_DOC; S_OC_ROLE; S_OC_SEND; S_OC_SOSG; S_OC_TCD
Try to use SOSG transaction instead. This transaction corresponds to transaction SOST but makes additional authorization checks.
I'd rather do the above requirement in this way:
Give to user authorization to T-code SOSG (via S_TCODE authorization object)
Create separate user group and add the relevant users to this group
Use authorization object S_OC_SOSG where you should strictly specify this group and type of send requests to display
You can create an PFCG (Role Maintenance) role with authorization field S_TCODE to limit the transaction codes could be executed by a user.
I'm using the parse REST API.
I need to setup so that for any requests made:
1) only logged in/authenticated users can Read or Write.
2) users can only access/modify records they own.
My current implementation:
1) using the Application key + REST API key.
2) sending request to user login endpoint, on success returning the user data including the session token
for 2), I'm not doing anything with the session token yet.
I understand that parse has:
1) class based permissions
2) object-level permissions (ACL's)
With Read and Write access on the class level, and by simply using the Application Key + REST API Keys,
anyone with these two keys can access that class (ofcourse, the Master Key has even more "power").
I want to simply say that they can Read and Write on the class level, if they're logged in/authenticated.
And when they Read, Update or Delete, they can only do so if they're owner of the object.
I assume that session token will play a role in the logged in part, and ownership is defined by object-level ACL
Is this correct and how to roughly set this scenario up in parse?
It's not clear to me in the REST API how to handle this (what I think is a common) type of scenario.
Thanks for any feedback
{"ACL":{"$CURRENT_USER":{"read":true,"write":true}}}
above in acl column will mean at the security level, only the creator has RW permissions. No other user can see these records with this ACL attr value regardless of their access on the CLASS level.
OR
you control the accessor predicates in your app. So you can add a column = 'createdBY' of type pointer_to_class_User.
Any queries just contain predicate ..
'where={"createdBy":{"__type":"Pointer","className":"User","objectId":"$CURRENT_USER"}}'
which enforces ( outside row security level ) idea of only getting result sets containing rows for the current-user.
all depends on how you want to use the security layer.
I would do it using the predicates and resort to the ACL only where you may have stuff like SSN's or Salary where as a policy you dont what general read permissions.