I am using wso2 identity server 4.5.0 and i' m wondering whether there is the option to give priority to the enforcement of a policy instead of another. For instance, the action A to resource X must be prior to the action B to resource X.
Thanks in advance!
Maria
I guess, you are asking about policy ordering... There can be multiple policies in the PDP policy store. For each XACML request, PDP would pick the applicable policy (or policies) based on policy’s Target element. When more than one policy is applicable for the request. Then PDP needs to combine the results of all applicable policies based on the policy combining algorithm. Applicable polices are evaluated based on the order that they have defined. Order of polices can be configured using Identity Server management console.. I guess you can find on this using this blog post...
Related
https://docs.aws.amazon.com/cognito/latest/developerguide/role-based-access-control.html#using-rules-to-assign-roles-to-users
As stated in the document:
Rules are evaluated in order, and the IAM role for the first matching rule is used, unless CustomRoleArn is specified to override the order. For more information about user attributes in Amazon Cognito user pools, see Configuring User Pool Attributes.
You can set multiple rules for an authentication provider in the identity pool (federated identities) console. Rules are applied in order. You can drag the rules to change their order. The first matching rule takes precedence. If the match type is NotEqual and the claim doesn't exist, the rule is not evaluated. If no rules match, the Role resolution setting is applied to either Use default Authenticated role or DENY.
My understanding is that we can customize these rules to map the JWT token's field to a specific AWS role granting.
Yet I couldn't find any options of creating/editing these rules on the AWS Console
Am I misreading the documentation? Or is this an undelivered feature or something?
It turns out that custom roles using Cognito Identity Pool only works with Cognito User Pool
User Pool can only be integrated with external SAML IDP (not JWT), so I think it's not possible to do access control for JWT bearers with Identity Pool
I guess what we can do is create multiple Identity Pools for multiple IAM Roles and do the access control from the IDP, even then we'll have to create multiple IDP clients for multiple Identity Pools
Is there a way to look up the permissions you'll need enabled in order to make a call to the AWS API?
For example, I want to call PutMetricAlarm on the CloudWatch API so I should need at least the Action cloudwatch:PutMetricAlarm Allowed on that resource. But what else is the minimum I need?
There is a one-to-one relationship between actions defined in the API and IAM actions.
In your example with PutMetricAlarm, no other permission than cloudwatch:PutMetricAlarm is needed.
The IAM action name (the part after the :) is always identical to the name of the action in the API.
The prefix (the part before the :) is a constant for each service but is not always identical to the service name (e.g. CloudWatch Logs is logs, Firewall Manager is fms).
Also note that the prefix and the action name are case insensitive.
Good references:
Actions, Resources, and Condition Keys for AWS Services
AWS Policy Generator
Complete AWS IAM Reference (cloudonaut)
For small CloudFormation and CodePipeline templates we could "try - test" to get least privilege IAM Policy for the roles required.
This usually involves:
Starting with a minimal policy
Creating the stack
It fails with - stack doesn't have rights to someService:someAction
Add the service action to the policy
update stack and try again
This approach is too time consuming for larger CloudFormation Templates.
How are you developing Least Privilege IAM Policies?
Ideas:
Allow "*" and then scrape cloudtrail for events and build map for listed events to their equivalent roles - then reduce the roles to only those listed in the cloudtrail logs.
If you can isolate actions down to a user name this helps
https://github.com/byu-oit-appdev/aws-cloudwatch-parse
Access Advisor
Grant least privilege is a well-documented IAM Best Practice. The documentation recommends incrementally adding specific permissions, using the Access Advisor tab to determine which services are actually being used by an application (presumably using a broader set of permissions during the testing phase):
It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later.
Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.
One feature that can help with this is the Access Advisor tab, which is available on the IAM console Summary page whenever you inspect a user, group, role, or policy. This tab includes information about which services are actually used by a user, group, role, or by anyone using a policy. You can use this information to identify unnecessary permissions so that you can refine your IAM policies to better adhere to the principle of least privilege. For more information, see Service Last Accessed Data.
This approach is similar to scraping CloudTrail for API events generated by a specific IAM Role/application, though the latter might be more difficult to filter through the entire event stream in order to find the relevant events, while the Access Advisor list is already filtered for you.
I would like to set up different AWS Identity and Access Management (IAM) users so that if an AWS resource is created by that IAM user, the resource is automatically assigned a specific tag.
For example: if IAM user F creates a new EC2 instance, the instance is automatically tagged as User:MrF. Is it possible to build a custom policy that does this?
My company GorillaStack have an open source lambda function that does exactly that.
The function 'listens' for CloudTrail logs to be delivered and tag the created resource with the ARN of the user that created it. It also support cross account tagging, for cases where a central account collects CloudTrail logs for other accounts.
Github: https://github.com/GorillaStack/auto-tag
Blog Post: http://blog.gorillastack.com/gorillastack-presents-auto-tag
It got a shout out at the 2015 re:Invent conference which is pretty cool :)
Hope that helps!
This is not available when using the AWS APIs directly (i.e. there's no way to command all AWS API's to tag new resources automatically on your behalf), however, depending on the specifics of your use case you could work around that limitation by correlating the creating user with the resource via post hoc tagging:
Workaround
You could activate AWS CloudTrail, which records AWS API calls for your account and delivers log files to you and provides exactly the information you are after:
The recorded information includes the identity of the API caller, the
time of the API call, the source IP address of the API caller, the
request parameters, and the response elements returned by the AWS
service.
Based on that information, a dedicated service of yours could analyze the logs and apply post hoc tags to all resources based on the logged user and created resource via the resp. API actions. Please see my answer to Which user launched EC2 instance? for some caveats/constraints to consider when going down this route.
An even better solution (faster plus I believe cheaper than parsing through CloudTrail logs) is to use CloudTrail but in combination with CloudWatch Events.
This is the basic concept described in a diagram
The implementation is detailed in this article:
https://blogs.aws.amazon.com/security/post/Tx150Z810KS4ZEC/How-to-Automatically-Tag-Amazon-EC2-Resources-in-Response-to-API-Events
The article also describes how to setup an IAM policy that only allows the creator of a resource to perform certain actions (like start / stop, describe, edit, terminate) against it.
I would chose AWS Config. Create a rule that automatically tags resources on creation. No cost, works across multiple accounts. Great for enforcing compliance. https://aws.amazon.com/about-aws/whats-new/2019/03/aws-config-now-supports-tagging-of-aws-config-resources/
Currently there is no such feature on IAM. If what you need is allow/deny based on user names, what you could do is use variables on your policy to allow or deny access based on naming conventions, e.g.:
...
"Resource":"arn:aws:dynamodb:us-east-!:123456789:table/ItemsCatalog_${aws:username}"
...
I have few doubts on configuring RBAC in WSO2:
are supported hierarchical roles?
is it possible to associate different roles to a user depending to a different authorization contexts? I.e. in DeptA a user can access a certain resource since having a manager role, while in DeptB cannot since having normal employee role.
RBAC can be implemented with XACML policies? Any sample policies available with hierarchical roles?
In WSO2-IS, it's the permission model that is hierarchical. Permissions can be assigned to a role in a fine-grained or a coarse-grained manner.
I think this is not straightforward.If the resource is identified with the Dept, we will be able to control it's permission there. If so this can be handled with XACML policies as well.
This sample policy may be of some help to you.
http://pushpalankajaya.blogspot.com/2013/06/xacml-30-policies-multiple-rules-5.html