Default authentication in almost all AWS services is AccessKeyId + SecretAccessKey (via HTTPS or other protocols used by wmio connectors). This is a basic, low-level or entry security. Normally, big companies or serious projects (like ours, both) want to have a centralized Identity Management with a product that can be reused in numerous third-party services. For it, IBM allows "Federated Authentication" using SAML or OIDC protocol from third party Identity Providers (see https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html ).
The authentication happens like this for the S3 service:
- App fetches token from third-party IdP
- App uses token to call sts.amazonaws.com with "AssumeRoleWithWebIdentity" action and receives in return a set of temporary aws credentials that can expire after a short time
- In all following requests to the S3, the app will send a AWS Signature v4 Authentication ( ttps://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) until this credential expires.
We need to have this option in the connector, to use a federated authentication.
I assume that there are multiple options to implement it (ordered from more complete and complex to entry-level and easier to provide):
A. New version of S3 connector that accepts a fields for fetching the third-party IdP token (example: url, client_id, client_secret, grant_type and scope - for OIDC), when the connector is used for the first time it will have to generate the token with the previous mentioned parameters. store it for reusage until expired, than send the request to sts to swap it for temporary session credentials and store them for reusage until expired, and than send request to the S3 service. For the following requests it will just have to use the saved credentials to reach the S3 or saved IdP token to resfresh the sts session.
B. The integration developer would handle the step 1 and 2 from above list and store the JWT and temporary STS session credentials for reusage, and IBM will provide a new version of S3 connector that doesn't expect mandatory AccessKeyId and SecretAccessKey, instead, when the connector is used inside the Flow Service, accepts three new parameters: the two mentioned before and the SessionToken (which is mandatory for the AWS Signature v4 in Federated authentication)
C. Create a built-in service for "AWS Signature v4", that accepts the temporary credentials, and the payload, will use them to encrypt and sign, and offer as output the signed body and all the values for the authentication headers required by AWS: X-Amz-Security-Token, X-Amz-Content-Sha256, X-Amz-Date and Authorization". The integration will have to manage the first two steps and implement the REST API Connector to invoke S3 via HTTPS.
Thank you,
Kind regards.
It seems that you already have some connectors with "Dynamic accounts".
Using dynamic accounts in predefined operations - IBM Documentation
Something similar, but for AWS S3