I'm writing a terraform template to setup escalation policies.
https://www.terraform.io/docs/providers/pagerduty/r/escalation_policy.html
I want to create an escalation policy to a specific user, but I don't know whether to specify user or user_reference as a value of rule.target.type. What's the difference between user and user_reference in PagerDuty API?
As a value of rule.target.type, user and user_reference are one and the same. Using either type should create an escalation policy that involves the specified user that is defined with rule.target.id.
Related
Snowflake follows the role-based access control (RBAC) paradigm. Best practice for RBAC is, to have functional and access roles managing either user and clients or access privileges. This creates in worst-case a variety of roles that inherits permissions from and to each other. By nature, one can easily lose sight.
In snowflake, grants to roles and users are stored in ACCESS_USAGE.GRANTS_TO_ROLES and ACCESS_USAGE.GRANTS_TO_USERS. What is a proper approach to identify the data stewards/owner of a role automatically (if not labeled explicitly in a 3rd party tooling)?
Options I thought of:
recursive lookup of OWNERSHIP privileges of roles of roles (will generate a lot of false positives)
recursive discovery of a service account that has advanced permission to a role and lookup the service account owner
lookup over usage pattern of executed queries (might be actually more consumers than producers)
A couple of options:
Populate the role’s comment field with the relevant Data Steward information
Use Tags (in public preview)
Given the example of a shop API with an orders resource. You would want to delete one order by id
DELETE /orders/:orderId
Under the hood you run an update query and set canceled to true. But what if
A customer calls this endpoint:
You need a canceledByCustomer database flag
No additional permissions are required
An administrator calls this endpoint?
You need a rejectedByAdministrator database flag
Additional permissions are required
Would you keep the endpoint posted above and check internally, if the calling user tries to cancel the order of another user and if true, this is a reject action?
Would you add two query parameters cancel and reject and one of them MUST be true and one of them MUST be null/false?
Would you violate the design rules, create two different endpoints and add verbs to them like so?
DELETE /orders/:orderId/cancel => customer can call it
DELETE /orders/:orderId/reject => only administrators can call it
Does someone know about the best practises for such "domain driven" problems?
API endpoints don't have to correlate on what happens closer to the core, for example in your Aggregate Root or CommandHandler. In my opinion, make the API routes as verbose as possible, which means creating their own separate routes for each use case. Push the logic on what database flag to use (canceledByCustomer vs rejectedByAdministrator) closer down to the entity.
I'm having trouble understanding the logic when evaluating permission for a shared resource.
Alice creates the resource aliceResource with the scopes read, create, delete
Alice creates the policy isAdmin that verifies if a user is admin
Alice creates a permission that applies the policy isAdmin to the resource aliceResource
Alice shares the resource aliceResource with the scope read to the user Bob
Evaluating permissions
For aliceResource in the scope read for bob with no role assigned.
Question 1. Why is it ignoring the policy isAdmin that is applied to the resource ?
For aliceResource in the scope delete for bob
Question 2. When bob has no role assigned, why the policy resource owner is granting read even though I'm evaluating for the scope delete ?
Question 3. When bob has the role admin, why is it the result permit ?, Alice shared the resource with bob for read not delete
I would appreciate if someone could help me understand what's going on.
Thanks
Edit 1.
I have my client evaluation strategy set to unanimous, what I would expect is for all the policies to apply but if I evaluate for a user that has role admin with whom the resource has not been shared, the decision is grant, how can I make the client enforce all the policies ?
Right now the client is doing an or between my policies and the policies created by keycloak when the resource is shared.
Keycloak did not crystal clear documentation for grant decisions.
This diagram is my understanding. The key is Client Decision Strategy
if set Affirmative, will OR logic.
if set Unanimous, will AND logic.
I made my own permissions(read, delete, and create) and policies. Each permission has a single scope (read, delete, or create). Bob assigned read policy, admin assigned all three policies. The permission decision strategy does not affect in this case (due to single assigned between permission and scope)
If set it with Disabled, any users can access the aliceResource.
This affects two cases by set client decision strategy. for bob
This affects two cases by set client decision strategy. for admin
So, if you want to allow bob only read scope and admin three scopes, the client decision should be Affirmative
This is my test decision results.
Is it possible to store multiple credentials for a given user in Keycloak?
They don't need to be all active/enabled at the same time. The use case for us is rather that we want to store new credentials in advance but don't want to have them active yet. They should be activated/enabled at a later time after some manual user verification.
The Keycloak REST API documentation states that UserRepresentation indeed comprises an array of CredentialRepresentation but in my few tests the GET call wouldn't even return a credentials attribute.
I would say that's impossible to have more credentials for a user.
But you can always implement your own user storage SPI that implements interface CredentialInputValidator, where you can check for the valid password.
Let's say in your DB, you have 2 colums for passwords: pas_col1 and pas_col2, and 1 more column as flag, which tells what column is used for user authentication, so in isValid(RealmModel realm, UserModel user, CredentialInput input) method you can check for your conditions.
Link to SPI: https://www.keycloak.org/docs/3.4/server_development/index.html#_user-storage-spi
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.