2
votes

I want to use OneLogin to write a command-line program that takes a username/password and generates a SAML assertion that can be used to authenticate to other sites.

The problem is that calling the "Generate SAML Assertion" API itself requires an access token generated from API credentials. So to distribute my app to users would require me to bake in API credentials to make that call. That would be fine, but the only authorization profile that allows callers to POST to the SAML resource is "Manage All", which is way more permission than is safe to give.

Has anyone done something like this?

OneLogin people, can you add an API credential type for calling only the SAML Assertion APIs? Or you could just make the API open. (Note that AWS's "AssumeRoleWithSAML" API doesn't require user credentials -- the whole point of the API is that you have credentials you want to convert to another credential type.)

3

3 Answers

1
votes

Do you give a developer a personal application to generate the SAML token or do you build a web service that returns a SAML token?

The former is bad (since the app has the key) the latter is infinitely more secure.

When we do lower the required rights to get a SAML assertion with a key (ID & secret) you should still look into building this as a web service. One your command line tool should call to get the SAML assertion.

Because contrary to popular opinion - Cloud-based means better security.

0
votes

We will be publishing an update shortly to lower the type of token to "Read/Write Users," since you are simply exchanging the user's credentials for the SAML assertion. Will that suffice?

Note: I initially mistakenly wrote "Read" instead of "Read/Write"

0
votes

There is now an Authentication Only API scope, which can be baked into your application.

The endpoints available in this scope include:

  • Verify Factor (SAML Assertion)
  • Generate SAML Assertion
  • Verify Factor (Login)
  • Create Session Login Token
  • Log User Out

Writing a web app to get the SAML assertation would be the best solution and let the CLI interact with it. Especially if you consider the "Log User Out", which can log out any given user as long as you can guess the ID (easy). If you trust your employees you could embed an Authentication Only scoped client ID/secret in your CLI. This is exactly what we will do at the first step with our OneLogin AWS-STS CLI tool. Of course we could have a rogue employee abusing this, but it's an edge case and really easy to revoke the client ID/secret and rollout a new version with a new client ID/secret.