Identity and Resource Policy

• Default policy - Implicit Deny
• Explicit Allow overrides Implicit Deny
• Explicit Deny overrides Explicit Allow
• User policy doesn't have Principal element, principal has been assumed to user/group whom policy is being applied
• Resource policy does have Principal
• User Policy Example :

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListAllMyBuckets"
         ],
         "Resource":"arn:aws:s3:::*"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket",
            "s3:GetBucketLocation"
         ],
         "Resource":"arn:aws:s3:::la-homefolders-bucket"
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:PutObject",
            "s3:PutObjectAcl",
            "s3:GetObject",
            "s3:GetObjectAcl",
            "s3:DeleteObject"
         ],
         "Resource":"arn:aws:s3:::la-homefolders-bucket/*"
      }
   ]
}

more here

• Resource Policy Example

{
  "Version":"1213",
  "Statement":[
    {
      Sid:"a"
      "Effect":"allow"
      "Principal":"*"
      "Action":[
        "s3:GetObject",
        "s3:PutObject"
      ]
      "Resource":[
        "arn:aws:s3:::la-home-folders-bucket"
      ]
    }
  ]
}

• There are a lot of available AWS Managed Policies that you can directly attach to your IAM Users, such as Administrator, Billing, Database Administrator, Data Scientist, Developer Power User, Network Administrator, Security Auditor, System Administrator and many others.
• For Administrators, you can use the AWS managed policy name: AdministratorAccess if you want to provision full access to a specific IAM User. This will enable the user to delegate permissions to every service and resource in AWS as this policy grants all actions for all AWS services and for all resources in the account.
• For Developer Power Users, you can use the AWS managed policy name: PowerUserAccess if you have users who perform application development tasks. This policy will enable them to create and configure resources and services that support AWS aware application development. The first statement of this policy uses the NotAction element to allow all actions for all AWS services and for all resources except AWS Identity and Access Management and AWS Organizations. The second statement grants IAM permissions to create a service-linked role. This is required by some services that must access resources in another service, such as an Amazon S3 bucket. It also grants Organizations permissions to view information about the user's organization, including the master account email and organization limitations.
• Resource based policy is supported by few services only:s3 buckets, glacier vault, sqs and sns. For rest of the service you have to assume role for cross account access.
• Cross Account access: For example Account A user x would like to assume the role on Account B in this case

• Account A should have role that user x can be assigned that permits it to sts:AssumeRole on resource arn:aws:iam::AccountB/rolex
• Account B should have trust policy that allows Account A to assumeRole in Account B and then Account B should have rolex that allows required resource access to principal AWS:arn:aws:iam::AccountA/root
• AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity and GetFederationToken API can also sent set of permission attached with request. It should be subset of actual permission associated with the role at destination or trusting account. Sending permission policy along with api request is not supported by GetSessionToken API

• To AssumeRoleWithWebIdentity inside our own web app

1. Register your app with aws recognized Idp (Amazon, Google, Facebook....) and get's an AppID.
2. Create a role for AppID that has all required permission
3. User need to be login to web app using one of the Idp using loging credential to the Idp.
4. Once loggedIn Idp provides OIDC ID token that should be passed with AssumeRoleWithWebIdentity api request to get temporary credentials (access key, secret access key, session token) that can be used to access permitted aws services.

• To AssumeRoleWithSAML

1. Any Idp that supports SMAL 2.0 can be identity provider for SAML authentication and authrozation. (Micorosoft AD)
2. On-premise Idp needs to be registered in AWS and also role needs to be created for the Idp.
3. Similarly AWS should also be registered as trusted entity inside Idp
4. When on-premise user try to access AWS, it would be redirected to single sign on page(login page with Idp).
5. In response to logged in request, Idp provides SAML assertion.
6. AssumeRoleWithSAML API request has been made along with SAML assertion, ARN of SAML provider and ARN of the Role to assume. It can also pass subset of the permission to restrict the access than what actual role has. In response it will get Access Key, Secret Access Key, Session token and expiry time.

• To GetFederationToken through Identity Broker/Proxy

1. When Corporate Identity Provider doesn't support SAML 2.0, this is the way to get temporary token using corporate credentials.
2. IAM user is created for Identity Broker on AWS with required permissions.
3. When User logs in using corporate credentials, Identity Broker verifies it with Corporate Identity Provider.
4. On successful verification Identity Broker, using it's IAM User credentials, makes a request to get temporary token either with same permission it has or attached the policy with subset of that permission and once get it, it would be passed to the user/app/browser that can use it for aws access

• AWS SSO supports only SAML 2.0–based applications so an OpenID Connect-compatible solution will not work for this scenario.
• Build a custom OpenID Connect-compatible solution for the user authentication functionality. Use Amazon Cognito Identity Pools for authorizing access to AWS resources is correct. The custom OpenID Connect-compatible solution will allow users to log in from their mobile application much like a single sign-on functionality. Amazon Cognito Identity Pool will provide temporary tokens to federated users for accessing AWS resources.
• Before you can use SAML 2.0-based federation, you must configure your organization's IdP and your AWS account to trust each other. Inside your organization, you must have an IdP that supports SAML 2.0, like Microsoft Active Directory Federation Service (AD FS, part of Windows Server), Shibboleth, or another compatible SAML 2.0 provider. In your organization's IdP, you define assertions that map users or groups in your organization to the IAM roles. Note that different users and groups in your organization might map to different IAM roles. The exact steps for performing the mapping depend on what IdP you're using. The role or roles that you create in IAM define what federated users from your organization are allowed to do in AWS. When you create the trust policy for the role, you specify the SAML provider that you created earlier as the Principal. You can additionally scope the trust policy with a Condition element to allow only users that match certain SAML attributes to access the role.
• AWS SSO does not support mobile apps.