We have successfully setup an external idP using google and connected it to AWS. Our users now have Federated SSO with AWS and can easily log into the web console with SAML 2.0 federation Role we created. This role also allows programmatic access but I can't find any documentation how to accomplish this. The normal way to do this is we create an IAM user who uses their own access keys with the CLI but in this case we don't have any IAM users… they are authenticating outside of AWS. Anyone have any ideas how to set this up?
AWS CLI SSO – Federated SSO to AWS Using CLI
amazon-web-servicesaws-clisingle-sign-on
Related Solutions
It looks like a number of things were wrong. Firstly, I didn't realize that the metadata needed to be recopied from my IdP back to the apache configs when I modified the SAML settings that side. Anyway, after making sure the IdP and SP xml files were configured correctly in Apache, I was able to move on (I think I had changed the entity ID)
I was still getting an error around requiring a valid user in the error logs. It turns out that MellonEnable "auth" takes care of ensuring there's a valid user, while for some reason, Require valid-user and AuthType "Mellon" parameters were triggering errors and 500 server responses.
After removing these 2 directives, I was still getting errors, this time Could not find metadata for the IdP "(null)" - after a quick search, it turns out that latest version of lasso available on Ubuntu 14.04 LTS (2.4.0) does not work with the SHA256 signatures that the IdP was defaulting to. Lasso 2.5 support SHA256. After updating the IdP config with a compatible algorithm, identification was taking place correctly.
However, I was then faced with redirect loops because of the context. I found another post that suggested moving the web root of splunk to a /splunk context instead of at root (/), and by updating this, I am now able to authenticate to Splunk via mellon from the IdP. Here's the relevant working configs:
MellonLockFile "/var/lock/mod_auth_mellon.lock"
MellonPostDirectory "/var/cache/apache2/mod_auth_mellon/"
ProxyRequests Off
ProxyPassInterpolateEnv On
# Move the proxy directives out of <location> and specify the context / mapping
ProxyPass /splunk http://127.0.0.1:8000/splunk
ProxyPassReverse /splunk http://127.0.0.1:8000/splunk
<Location />
MellonEnable "info"
MellonVariable "cookie"
MellonSamlResponseDump On
MellonSPPrivateKeyFile /etc/apache2/mellon/urn_splunkweb.key
MellonSPCertFile /etc/apache2/mellon/urn_splunkweb.cert
MellonSPMetadataFile /etc/apache2/mellon/urn_splunkweb.xml
MellonIdpMetadataFile /etc/apache2/mellon/idp-metadata.xml
MellonEndpointPath /secret/endpoint
MellonUser "NAME_ID"
MellonDefaultLoginPath /splunk/en-US/
RequestHeader set SplunkWebUser %{MELLON_NAME_ID}e
ProxyPassInterpolateEnv On
</Location>
<Location /splunk/>
# Forces /splunk requests to be authenticated via the IdP.
MellonEnable "auth"
</Location>
$SPLUNK_HOME/etc/system/local/web.conf:
[settings]
trustedIP=127.0.0.1
remoteUser SplunkWebUser
SSOMode=permissive
root_endpoint = /splunk
And $SPLUNK_HOME/etc/system/local/server.conf
[general]
trustedIP=127.0.0.1
This is obviously for a setup where the apache/mellon server runs on the same host as splunk. web.conf (splunk) and auth_mellon.conf (apache) need to be updated with remote IPs if not. web.conf supports a comma-separated list of trusted hosts, while server.conf doesn't and should stay as localhost.
As Michael has stated in the comments, the issue was permissions.
The only permission required was 'kms:CreateGrant' which has been added to the service user used to run the CLI commands.
Best Answer
This is doable, but not very convenient. A Chrome plugin exists to extract the access-key, secret-key, and security-token values (needed for an STS login through CLI) after logging in to the AWS Console through SAML. This handles the back-n-forth between the identity provider and the SAML endpoint for AWS.
For a pure-CLI solution, I'm afraid you're going to have to do some scripting. The route is described in the AWS documentation, but involves:
AssumeRoleWithSAMLAPI endpoint (aws sts assume-role-with-saml)At that point, you have credentials. Once you apply them to your environment, CLI commands work the way they always have. For unattended scripts, your ability to use this route depends entirely on your IdP's ability to allow that workflow.