使用Cognito对AWS服务进行未经身份验证的访问

Question

I am trying to write a simple JavaScript (running in browser), that will get information about my Beanstalk applications with describeApplications function. I've created Cognito Identity Pool with unauthenticated access checkbox set and attached AWSElasticBeanstalkReadOnlyAccess policy to the Role of Identity Pool.

Here is the code:

<script src="https://sdk.amazonaws.com/js/aws-sdk-2.134.0.min.js"></script>
<script>
    AWS.config.region = 'eu-west-1'; // Region

    AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        IdentityPoolId: 'eu-west-1:....',
    });

    var elasticbeanstalk = new AWS.ElasticBeanstalk();
    elasticbeanstalk.describeApplications({}, function (err, data) {
        if (err) {
            console.log(err);
            console.log(err.stack);
        } else {
            console.log(data);
        }
    });

Here is the output in console:

{ResponseMetadata: {…}, Applications: Array(0)}

Applications array is empty! But I definitely have applications in eu-west-1 region.

To make a simple test I created a user, attached same policy and hard coded user credentials instead of CognitoIdentityCredentials:

<script src="https://sdk.amazonaws.com/js/aws-sdk-2.134.0.min.js"></script>
<script>
    AWS.config.region = 'eu-west-1'; // Region

    AWS.config.accessKeyId = '...';
    AWS.config.secretAccessKey = '...';

    var elasticbeanstalk = new AWS.ElasticBeanstalk();
    elasticbeanstalk.describeApplications({}, function (err, data) {
        if (err) {
            console.log(err);
            console.log(err.stack);
        } else {
            console.log(data);
        }
    });

And voila, I see my beanstalk applications:

{ResponseMetadata: {…}, Applications: Array(1)}

I have done other tests. I tried to list S3 buckets with unauth. access and Cognito - it also works. That means my unauth. role is properly attached and applied. But I have no idea, why I see no applications in beanstalk!

What am I doing wrong with unauthenticated access and Cognito? Any help will be really appreciated!

Update!

Thanks Mike Patrick for pointing to the right direction! https://stackoverflow.com/a/46820122/1858818

I switched to basic authentication flow and that was it. Here is the working piece of code:

AWS.config = {
    apiVersions: { elasticbeanstalk: '2010-12-01' },
    region: 'eu-west-1',
    credentials: new AWS.WebIdentityCredentials({
        RoleArn: 'my role arn'
    })
};            

var cognitoidentity = new AWS.CognitoIdentity(),
    elasticbeanstalk = new AWS.ElasticBeanstalk();

var params = {
    IdentityPoolId: 'my cognito identity pool id', /* required */
};
cognitoidentity.getId(params, function(err, data) {
    if (err){
        console.log(err, err.stack); // an error occurred
    } else {
        var params = {
            IdentityId: data.IdentityId
        };
        cognitoidentity.getOpenIdToken(params, function(err, data) {
            if (err) {
                console.log(err, err.stack); // an error occurred
            } else {

                AWS.config.credentials.params.WebIdentityToken = data.Token;

                //here we go, elasticbeanstalk functions work as expected

            }
        });        
    }
});

Answer 1

I'm not convinced you're doing anything wrong; I was also unable to make this work. I suspect you may be a victim of Amazon "protecting" you from yourself.

From http://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html under "Access Policies":

For additional security protection, Amazon Cognito applies a scope-down policy to credentials vended by GetCredentialForIdentity to prevent access to services other than these to your unauthenticated users :

... list of services that does NOT include Elastic Beanstalk ...

If you need access to something other than these services for your unauthenticated users, you must use the basic authentication flow.

This seems to suggest that regardless of what policies you attach to your Cognito Unauthenticated role, AWS is going to "scope it down".

If this is the case, you'd like to see some evidence of a NotAuthorizedException (often in a response header), but I couldn't find any.