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.
Related
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.
How do I create multiple authorizations for an order?
According to the docs:
An order is valid for 29 days. During this period, you can request from one to ten or more authorizations to ensure the availability of funds. By default, you can make up to ten basic authorizations for each order. https://developer.paypal.com/docs/integration/direct/payments/orders/#overview
I tried creating an order with intent=authorize and then post with
https://api.paypal.com/v2/checkout/orders/orderId/authorize
First it succeeded, yet when I want to create another authorization, it gave me error:
issue":"ORDER_ALREADY_AUTHORIZED","description":"Order already authorized.If 'intent=AUTHORIZE' only one authorization per order is allowed." "debug_id":"47084737aefa3"
So I canceled the original authorization and then tried to create a new one, still got the same error.
Then I changed intent=capture, it gave me
"name":"UNPROCESSABLE_ENTITY","details":[{"issue":"ACTION_DOES_NOT_MATCH_INTENT","description":"Order was created with an intent to 'CAPTURE'. Please use v2/checkout/orders/order_id/capture to complete the transaction or alternately Create an order with an intent of 'AUTHORIZE'."
"message":"The requested action could not be performed, semantically incorrect, or failed business validation.","debug_id":"8c381672a8f1e"
Any help would be much appreciated!!!
The documentation you linked to is for v1/payments/orders, which are deprecated and very different in function and purpose from v2/checkout/orders.
v2/checkout/orders can only be captured a single time. An intervening authorization step is optional, if you need it.
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.
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.
We are building a REST API with the following resources: Users, UserGroups. Currently we are supporting the following URI's:
/BASEAPI/VERSION/Users/
/BASEAPI/VERSION/Users/{id}/UserGroups
/BASEAPI/VERSION/UserGroups/
/BASEAPI/VERSION/UserGroups/{id}/Users
I like this better than including references in the objects which then have to be pulled on subsequent requests. It also means that we can avoid query params to filter the results. i.e. we don't have to support:
/BASEAPI/VERSION/UserGroups/{id}?user_id={user_id}
The problem is that it doesn't make creation and deletion semantics very clear. i.e. should a DELETE request to:
/BASEAPI/VERSION/Users/{id}/UserGroups/{group_id}
remove the UserGroup, or remove the user from the user group?
We've considered adding:
/BASEAPI/VERSION/UserGroupUsers
But something doesn't quite feel right about that, but maybe it's the best way to go. What do others think are best practices?
You need to figure out how you intend to represent the membership relationship between user and user group. It can be an attribute of the user, an attribute of the group, or a separate resource. Those are the only choices. How users are added to and removed from groups falls out naturally from your choice. Membership management becomes a PUT/DELETE to the user, the group, or the membership resource.
Personally, I find the separate resource to be the cleanest way to handle the issue, but you then need query parameters to poll for a specific user or group. Also, you'd need to change your second-level resource names, because it makes no sense for /userGroups/{id}/users to return a collection of userGroupUsers resources.
A URL addresses a resource. A GET on this URL returns the resource and a DELETE deletes it. If the DELETE would delete something different than the GET is returning something really is broken.
So if /BASEAPI/VERSION/Users/4711/UserGroups would return the UserGroups with the ID 0815 and 0816 the DELETE should delete both userGroups.
Question is: Does this make sense? What is happening to the other users in both userGroups?
If you want to remove a user from a group I would provide a PATCH Method.