SAML Assumed-Role user not authorized to perform actions

I'm using OKTA as our Identity Provider which is allowing me to dictate which Roles users can Assume when logging into the Console.

The Goal:
Have a Role that allows a user to log into the console and only manage their Access Keys (List, Create, Update, Delete).

This Policy should allow the current user to manage their own keys but I get this error when trying to do anything other than List the access keys

User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/AccessKeyManagement/[Logged In Username] is not authorized to perform: iam:CreateAccessKey on resource: user [Logged In Username]

Granted if I change the Resource to be "*" it will work but the user can alter other account Access Keys.

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "sts:AssumeRole",

                "sts:DecodeAuthorizationMessage",

                "iam:ListAccountAliases",

                "iam:ListUsers",

                "sts:GetCallerIdentity",

                "iam:ListAccessKeys"

            ],

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "iam:DeleteAccessKey",

                "iam:UpdateAccessKey",

                "iam:CreateAccessKey"

            ],

            "Resource": "arn:aws:iam::*:user/${aws:username}"

        }

    ]

}

Role Trusted Relationships (just in case it's needed)

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "arn:aws:iam::[ACCOUNT-NUMBER]:saml-provider/OKTA"

      },

      "Action": [

        "sts:AssumeRoleWithSAML",

        "sts:AssumeRole"

      ],

      "Condition": {

        "StringEquals": {

          "SAML:aud": "https://signin.aws.amazon.com/saml"

        }

      }

    }

  ]

}

I'm at a loss as to what I need to do to allow the "Assumed-Role" of the current user permission to modify the Access keys.

asked Nov 20 '18 at 20:14

funkyfreshmonkey

see if ${aws:userid} works.

– Asdfg
Nov 20 '18 at 20:54

You may also try to add account number instead of * in resources as arn:aws:iam::123456789012:user/${aws:username}

– Asdfg
Nov 20 '18 at 21:02

@Asdfg ${aws:userid} didn't work. When i hardcode the user arn:aws:iam::123456789012:user/jim everything works as expected. But when i try to add the dynamic username it fails.

– funkyfreshmonkey
Nov 21 '18 at 21:59

add a comment |

I'm using OKTA as our Identity Provider which is allowing me to dictate which Roles users can Assume when logging into the Console.

The Goal:
Have a Role that allows a user to log into the console and only manage their Access Keys (List, Create, Update, Delete).

This Policy should allow the current user to manage their own keys but I get this error when trying to do anything other than List the access keys

User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/AccessKeyManagement/[Logged In Username] is not authorized to perform: iam:CreateAccessKey on resource: user [Logged In Username]

Granted if I change the Resource to be "*" it will work but the user can alter other account Access Keys.

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "sts:AssumeRole",

                "sts:DecodeAuthorizationMessage",

                "iam:ListAccountAliases",

                "iam:ListUsers",

                "sts:GetCallerIdentity",

                "iam:ListAccessKeys"

            ],

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "iam:DeleteAccessKey",

                "iam:UpdateAccessKey",

                "iam:CreateAccessKey"

            ],

            "Resource": "arn:aws:iam::*:user/${aws:username}"

        }

    ]

}

Role Trusted Relationships (just in case it's needed)

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "arn:aws:iam::[ACCOUNT-NUMBER]:saml-provider/OKTA"

      },

      "Action": [

        "sts:AssumeRoleWithSAML",

        "sts:AssumeRole"

      ],

      "Condition": {

        "StringEquals": {

          "SAML:aud": "https://signin.aws.amazon.com/saml"

        }

      }

    }

  ]

}

I'm at a loss as to what I need to do to allow the "Assumed-Role" of the current user permission to modify the Access keys.

asked Nov 20 '18 at 20:14

funkyfreshmonkey

see if ${aws:userid} works.

– Asdfg
Nov 20 '18 at 20:54

You may also try to add account number instead of * in resources as arn:aws:iam::123456789012:user/${aws:username}

– Asdfg
Nov 20 '18 at 21:02

@Asdfg ${aws:userid} didn't work. When i hardcode the user arn:aws:iam::123456789012:user/jim everything works as expected. But when i try to add the dynamic username it fails.

– funkyfreshmonkey
Nov 21 '18 at 21:59

add a comment |

I'm using OKTA as our Identity Provider which is allowing me to dictate which Roles users can Assume when logging into the Console.

The Goal:
Have a Role that allows a user to log into the console and only manage their Access Keys (List, Create, Update, Delete).

This Policy should allow the current user to manage their own keys but I get this error when trying to do anything other than List the access keys

User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/AccessKeyManagement/[Logged In Username] is not authorized to perform: iam:CreateAccessKey on resource: user [Logged In Username]

Granted if I change the Resource to be "*" it will work but the user can alter other account Access Keys.

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "sts:AssumeRole",

                "sts:DecodeAuthorizationMessage",

                "iam:ListAccountAliases",

                "iam:ListUsers",

                "sts:GetCallerIdentity",

                "iam:ListAccessKeys"

            ],

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "iam:DeleteAccessKey",

                "iam:UpdateAccessKey",

                "iam:CreateAccessKey"

            ],

            "Resource": "arn:aws:iam::*:user/${aws:username}"

        }

    ]

}

Role Trusted Relationships (just in case it's needed)

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "arn:aws:iam::[ACCOUNT-NUMBER]:saml-provider/OKTA"

      },

      "Action": [

        "sts:AssumeRoleWithSAML",

        "sts:AssumeRole"

      ],

      "Condition": {

        "StringEquals": {

          "SAML:aud": "https://signin.aws.amazon.com/saml"

        }

      }

    }

  ]

}

I'm at a loss as to what I need to do to allow the "Assumed-Role" of the current user permission to modify the Access keys.

asked Nov 20 '18 at 20:14

funkyfreshmonkey

I'm using OKTA as our Identity Provider which is allowing me to dictate which Roles users can Assume when logging into the Console.

The Goal:
Have a Role that allows a user to log into the console and only manage their Access Keys (List, Create, Update, Delete).

This Policy should allow the current user to manage their own keys but I get this error when trying to do anything other than List the access keys

User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/AccessKeyManagement/[Logged In Username] is not authorized to perform: iam:CreateAccessKey on resource: user [Logged In Username]

Granted if I change the Resource to be "*" it will work but the user can alter other account Access Keys.

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "sts:AssumeRole",

                "sts:DecodeAuthorizationMessage",

                "iam:ListAccountAliases",

                "iam:ListUsers",

                "sts:GetCallerIdentity",

                "iam:ListAccessKeys"

            ],

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "iam:DeleteAccessKey",

                "iam:UpdateAccessKey",

                "iam:CreateAccessKey"

            ],

            "Resource": "arn:aws:iam::*:user/${aws:username}"

        }

    ]

}

Role Trusted Relationships (just in case it's needed)

{

  "Version": "2012-10-17",

  "Statement": [

    {

      "Effect": "Allow",

      "Principal": {

        "Federated": "arn:aws:iam::[ACCOUNT-NUMBER]:saml-provider/OKTA"

      },

      "Action": [

        "sts:AssumeRoleWithSAML",

        "sts:AssumeRole"

      ],

      "Condition": {

        "StringEquals": {

          "SAML:aud": "https://signin.aws.amazon.com/saml"

        }

      }

    }

  ]

}

I'm at a loss as to what I need to do to allow the "Assumed-Role" of the current user permission to modify the Access keys.

amazon-web-services amazon-iam aws-sts

asked Nov 20 '18 at 20:14

funkyfreshmonkey

asked Nov 20 '18 at 20:14

funkyfreshmonkey

asked Nov 20 '18 at 20:14

funkyfreshmonkey

asked Nov 20 '18 at 20:14

funkyfreshmonkey

asked Nov 20 '18 at 20:14

funkyfreshmonkey

see if ${aws:userid} works.

– Asdfg
Nov 20 '18 at 20:54

You may also try to add account number instead of * in resources as arn:aws:iam::123456789012:user/${aws:username}

– Asdfg
Nov 20 '18 at 21:02

@Asdfg ${aws:userid} didn't work. When i hardcode the user arn:aws:iam::123456789012:user/jim everything works as expected. But when i try to add the dynamic username it fails.

– funkyfreshmonkey
Nov 21 '18 at 21:59

add a comment |

see if ${aws:userid} works.

– Asdfg
Nov 20 '18 at 20:54

You may also try to add account number instead of * in resources as arn:aws:iam::123456789012:user/${aws:username}

– Asdfg
Nov 20 '18 at 21:02

@Asdfg ${aws:userid} didn't work. When i hardcode the user arn:aws:iam::123456789012:user/jim everything works as expected. But when i try to add the dynamic username it fails.

– funkyfreshmonkey
Nov 21 '18 at 21:59

see if ${aws:userid} works.

– Asdfg
Nov 20 '18 at 20:54

You may also try to add account number instead of * in resources as arn:aws:iam::123456789012:user/${aws:username}

– Asdfg
Nov 20 '18 at 21:02

@Asdfg ${aws:userid} didn't work. When i hardcode the user arn:aws:iam::123456789012:user/jim everything works as expected. But when i try to add the dynamic username it fails.

– funkyfreshmonkey
Nov 21 '18 at 21:59

add a comment |

1 Answer
1

active

oldest

votes

So, an IAM role does not have permanent access key associated with it and you get temporary credentials (access keys, secret key and session token) when you login to the console.
Now, the "${aws:username}" resolves to IAM user name and it does not apply to IAM role. Thus you can't manage the access key creation of IAM roles and you don't have to.

answered Nov 20 '18 at 20:39

sudo

1,1741310

Some users still need access keys for their tasks and we want them to be able to manage their own keys. We do want to resolve the IAM username because the IAM Username must be the same as what is configured on the SAML side.

– funkyfreshmonkey
Nov 21 '18 at 22:00

If your users need access keys, you can use programmatically retrieve it but you might have to write the code depending which SAML provider you're using. You cannot resolve the IAM role with SAML federation to IAM username as those are two different entities. For IAM user, the authentication is taken care by AWS where when you use SAML it happens at your Identity Provider. So when you are using SAML, the username attribute itself is not similar to IAM user name. Using IAM role is the whole point of not to mange IAM users and their long term credentials.

– sudo
Nov 23 '18 at 20:52

I see you are using Okta. You might have a look in the article from Okta: support.okta.com/help/s/article/…

– sudo
Nov 23 '18 at 21:00

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53400840%2fsaml-assumed-role-user-not-authorized-to-perform-actions%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

answered Nov 20 '18 at 20:39

sudo

1,1741310

Some users still need access keys for their tasks and we want them to be able to manage their own keys. We do want to resolve the IAM username because the IAM Username must be the same as what is configured on the SAML side.

– funkyfreshmonkey
Nov 21 '18 at 22:00

If your users need access keys, you can use programmatically retrieve it but you might have to write the code depending which SAML provider you're using. You cannot resolve the IAM role with SAML federation to IAM username as those are two different entities. For IAM user, the authentication is taken care by AWS where when you use SAML it happens at your Identity Provider. So when you are using SAML, the username attribute itself is not similar to IAM user name. Using IAM role is the whole point of not to mange IAM users and their long term credentials.

– sudo
Nov 23 '18 at 20:52

I see you are using Okta. You might have a look in the article from Okta: support.okta.com/help/s/article/…

– sudo
Nov 23 '18 at 21:00

add a comment |

answered Nov 20 '18 at 20:39

sudo

1,1741310

Some users still need access keys for their tasks and we want them to be able to manage their own keys. We do want to resolve the IAM username because the IAM Username must be the same as what is configured on the SAML side.

– funkyfreshmonkey
Nov 21 '18 at 22:00

If your users need access keys, you can use programmatically retrieve it but you might have to write the code depending which SAML provider you're using. You cannot resolve the IAM role with SAML federation to IAM username as those are two different entities. For IAM user, the authentication is taken care by AWS where when you use SAML it happens at your Identity Provider. So when you are using SAML, the username attribute itself is not similar to IAM user name. Using IAM role is the whole point of not to mange IAM users and their long term credentials.

– sudo
Nov 23 '18 at 20:52

I see you are using Okta. You might have a look in the article from Okta: support.okta.com/help/s/article/…

– sudo
Nov 23 '18 at 21:00

add a comment |

answered Nov 20 '18 at 20:39

sudo

1,1741310

answered Nov 20 '18 at 20:39

sudo

1,1741310

answered Nov 20 '18 at 20:39

sudo

1,1741310

answered Nov 20 '18 at 20:39

sudo

1,1741310

answered Nov 20 '18 at 20:39

sudo

1,1741310

Some users still need access keys for their tasks and we want them to be able to manage their own keys. We do want to resolve the IAM username because the IAM Username must be the same as what is configured on the SAML side.

– funkyfreshmonkey
Nov 21 '18 at 22:00

If your users need access keys, you can use programmatically retrieve it but you might have to write the code depending which SAML provider you're using. You cannot resolve the IAM role with SAML federation to IAM username as those are two different entities. For IAM user, the authentication is taken care by AWS where when you use SAML it happens at your Identity Provider. So when you are using SAML, the username attribute itself is not similar to IAM user name. Using IAM role is the whole point of not to mange IAM users and their long term credentials.

– sudo
Nov 23 '18 at 20:52

I see you are using Okta. You might have a look in the article from Okta: support.okta.com/help/s/article/…

– sudo
Nov 23 '18 at 21:00

add a comment |

Some users still need access keys for their tasks and we want them to be able to manage their own keys. We do want to resolve the IAM username because the IAM Username must be the same as what is configured on the SAML side.

– funkyfreshmonkey
Nov 21 '18 at 22:00

If your users need access keys, you can use programmatically retrieve it but you might have to write the code depending which SAML provider you're using. You cannot resolve the IAM role with SAML federation to IAM username as those are two different entities. For IAM user, the authentication is taken care by AWS where when you use SAML it happens at your Identity Provider. So when you are using SAML, the username attribute itself is not similar to IAM user name. Using IAM role is the whole point of not to mange IAM users and their long term credentials.

– sudo
Nov 23 '18 at 20:52

I see you are using Okta. You might have a look in the article from Okta: support.okta.com/help/s/article/…

– sudo
Nov 23 '18 at 21:00

Some users still need access keys for their tasks and we want them to be able to manage their own keys. We do want to resolve the IAM username because the IAM Username must be the same as what is configured on the SAML side.

– funkyfreshmonkey
Nov 21 '18 at 22:00

If your users need access keys, you can use programmatically retrieve it but you might have to write the code depending which SAML provider you're using. You cannot resolve the IAM role with SAML federation to IAM username as those are two different entities. For IAM user, the authentication is taken care by AWS where when you use SAML it happens at your Identity Provider. So when you are using SAML, the username attribute itself is not similar to IAM user name. Using IAM role is the whole point of not to mange IAM users and their long term credentials.

– sudo
Nov 23 '18 at 20:52

I see you are using Okta. You might have a look in the article from Okta: support.okta.com/help/s/article/…

– sudo
Nov 23 '18 at 21:00

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu