Mohamed Zenadi zeapo @WattSense Lyon, France Software Engineer @WattSense

android-password-store/Android-Password-Store 1590

Android application compatible with ZX2C4's Pass command line application

zeapo/barberousse 15

Remote Secret Editor for AWS Secret Manager

zeapo/genpiepie 2

Simple password generator in python

zeapo/abcd 1

The Augmented Block Cimmino Distributed Solver

zeapo/android-app 0

Code and issue about EchOpen display -- now on, #Android -- Perhaps some duplication with

zeapo/AndroidProgressLayout 0

Android View to simplify working with ProgressBar

zeapo/anko 0

Pleasant Android application development

zeapo/appstart 0

Tool for running a GAE MVM emulation environment.

zeapo/arrow 0

Mirror of Apache Arrow


started time in 9 days


started time in 9 days


started time in 10 days


started time in 12 days


started time in 15 days

push eventzeapo/rusoto

Mohamed Zenadi

commit sha cad8116c20cfb9c0cdd72ab9f43ee5fc57af2bfe

fix bad refactoring

view details

push time in 16 days

PR opened rusoto/rusoto

support creating an sts cred provider from profiles

This will allow the user to create an StsAssumeRoleSessionCredentialsProvider using a profile provider using a new function with_profile_provider().

It solves the issues #1834 , #1758 and #1559. However, contrary to other SDKs, this is not an automatic way of using a profile. Here's an example from one of the projects I've been working on, in which I've tested it this feature first:

                let profile_provider = ProfileProvider::with_default_credentials(profile)?;

                let assume = StsAssumeRoleSessionCredentialsProvider::with_profile_provider(

                if let Ok(assume) = assume {
                        HttpClient::new().expect("failed to create request dispatcher"),
                } else {
                        HttpClient::new().expect("failed to create request dispatcher"),

Notice that this tries to assume a role, or switches to the profile itself if it fails, for instance if the profile does not contain the required keys to assume a role.


  • The profile's function parse_credentials_file was split into two. It now parses the credentials and returns a HashMap, so that all keys can be exploited and provided to other clients needing access to these properties via ProfileProvider::properties()
  • An ugly list of valid keys (I still have to find a nicer way, maybe the same way we handle Region enum??) that is used to extract only valid keys from the credentials file
  • A new StsAssumeRoleSessionCredentialsProvider::with_profile_provider() that creates a StsAssumeRoleSessionCredentialsProvider using a profile provider only

What I don't like in this

  • Having to call HttpClient::new().expect("failed to create request dispatcher") to create a dispatcher. Maybe add a constructor that does it automatically? This will avoid having to do it for all clients (see example above for SecretsManagerClient)
  • No automatic way to default to the profile provider as a credentials provider. I'm guessing we should have something like StsProfileCredentialsProvider that handles this case and during the call to credentials(), feel free to suggest new ideas


  • The key role_session_name has to be set in your profile. Yes, it's not mandatory by aws, but StsAssumeRoleSessionCredentialsProvider requires it. Either we generate it automatically in the call to with_profile_provider (in case it's absent), or make it optional.
+185 -67

0 comment

4 changed files

pr created time in 16 days

create barnchzeapo/rusoto

branch : sts-profile-credentials-provider

created branch time in 16 days

push eventzeapo/barberousse

Mohamed Zenadi

commit sha ff8666acfda5065a777c8d2ed9851d00267a19f0

support sts profile assume

view details

push time in 16 days

issue commentrusoto/rusoto

Rusoto automatic providers do not apply source_profile or role_arn

This is more difficult than it would seem at first because the STS API calls necessary are in rusoto_sts, which ultimately depend on rusoto_credential, and we can't have a circular dependency. This is why there are some credential providers in rusoto_sts, but none of them read from the profile (yet).

@iliana I started working on a solution where parsing the profile checks for all potential keys defined by the credentials' spec and exposes it into a hash. Then an StsProfileCredentialsProvider would take a ProfileProvider and does the job in assuming the profile requested in the latter.

User friendliness wise, we can't automatically guess if the rusoto_sts crate was added (as far as my rust knowledge goes). Therefore we can't mimic other SDKs (such as Java that uses Sts if the jar is in the classpath). Therefore, the user will have to manually rely on the StsProfileCredentialsProvider. Which ofc will default to ProfileCredentialsProvider if the selected profile is indeed a simple credentials profile and does not need to assume a role.

I'll open a PR this weekend or next week when it's finished


comment created time in 21 days


started time in 23 days


started time in a month

issue openedrusoto/rusoto

Profile based STS Credentials

The current way of handling profiles is quite limiting. It assumes that the profile in the credentials file has explicit access_key and secret. However, the way the cli and the java sdk (I don't know about the other sdks) go further.

For instance, if you have in your credentials file:

aws_access_key_id = KEY
aws_secret_access_key = SEC

role_arn = arn:aws:iam::act_id:role/role_name
source_profile = profile_one

would make it possible to use profile_two by automatically assuming the role (in the Java SDK you need to include the sts dependencies).

In rusoto, we're quite limited, if we try to use profile_two, we'd get a "profile not found" error.

  • The parse_credentials_file does not care about all the potential keys that could be used in other services (such as sts). A fix would be to handle this just like the java sdk does it, i.e. by creating a ProfileFile struct that would allow us to branch to either AwsCredentials or extract needed information to assume the role
    • Most (if not all) of the functions related to file location / parsing the credentials, would move to this struct impl. The profile provider would be lighter and depends on this struct to keep its current behaviour.
  • StsAssumeRoleSessionCredentialsProvider requires explicit values (due to the lack of the previous feature) to work.

I'd be happy to work on these to features in two different PRs (in order). However, I'd like your opinion on the matter.

created time in a month


started time in 2 months

fork zeapo/aws-ec2-assign-elastic-ip

Automatically assign Elastic IPs to AWS EC2 Auto Scaling Group instances

fork in 2 months

create barnchzeapo/barberousse

branch : listing

created branch time in 2 months


started time in 2 months


started time in 2 months

created tagzeapo/barberousse


Remote Secret Editor for AWS Secret Manager

created time in 3 months

push eventzeapo/barberousse

Mohamed Zenadi

commit sha 91663c7de7ab3f851115d64172b4ebe5952dd587

bump version 0.1.6 (cargo fixes)

view details

push time in 3 months

created tagzeapo/barberousse


Remote Secret Editor for AWS Secret Manager

created time in 3 months

push eventzeapo/barberousse

Mohamed Zenadi

commit sha cae1dd94923c1e4d82fd158c7351e1fff8fb3445

bump version 0.1.5

view details

push time in 3 months