Show HN: Saml.to: I've Turned GitHub into a SAML Identity Provider(saml.to)
saml.to
Show HN: Saml.to: I've Turned GitHub into a SAML Identity Provider
https://saml.to
6 comments
Sounds interesting. What's a use case for this?
Hey brianr! thanks for the question
Let's actually use Rollbar as a use case since your HN profile says you're the co-founder, and Rollbar supports SAML !
Use case:
There's a set of developers on a project in GitHub, that also need to log into Rollbar. Rollbar would be added as a provider in the SAML.to Configuration File (hosted in GitHub). Developers that need to access Rollbar would also be listed in the configuration file with who should be allowed to Login to Rollbar.
Here's a sample of the config file: https://gist.github.com/cnuss/4966f227afdd6a134e74ad579c9c7c...
When "cnuss" or "brianr" needs to access Rollbar, they would run the command in their console
`npx saml-to login rollbar`
This command would obtain their GitHub identity, and open a browser window directly into Rollbar. "tonystark" would not be able to do this, since he's not listed.
Additionaly, in this config, AWS access is configured for role assumption, So brianr, cnuss, and tonystark can all log AWS using the command
`npx saml-to assume role/admin`
This command would open up a browser window in the AWS console with the role of "arn:aws:iam::01234567890:role/admin"!
Using two commands, developers were able to log into both AWS and Rollbar in seconds.
Also, with SAML.to Premium, listing individual users is unnecessary, and assigning them to teams and specifying the teams in the config eliminates the repetition of a list of users in the config file.
Let me know if you have any questions or comments!
Let's actually use Rollbar as a use case since your HN profile says you're the co-founder, and Rollbar supports SAML !
Use case:
There's a set of developers on a project in GitHub, that also need to log into Rollbar. Rollbar would be added as a provider in the SAML.to Configuration File (hosted in GitHub). Developers that need to access Rollbar would also be listed in the configuration file with who should be allowed to Login to Rollbar.
Here's a sample of the config file: https://gist.github.com/cnuss/4966f227afdd6a134e74ad579c9c7c...
When "cnuss" or "brianr" needs to access Rollbar, they would run the command in their console
`npx saml-to login rollbar`
This command would obtain their GitHub identity, and open a browser window directly into Rollbar. "tonystark" would not be able to do this, since he's not listed.
Additionaly, in this config, AWS access is configured for role assumption, So brianr, cnuss, and tonystark can all log AWS using the command
`npx saml-to assume role/admin`
This command would open up a browser window in the AWS console with the role of "arn:aws:iam::01234567890:role/admin"!
Using two commands, developers were able to log into both AWS and Rollbar in seconds.
Also, with SAML.to Premium, listing individual users is unnecessary, and assigning them to teams and specifying the teams in the config eliminates the repetition of a list of users in the config file.
Let me know if you have any questions or comments!
Enables using Github for single-sign-on (SSO), which is subtly different than using Github for sign-in on multiple online properties.
Greetings Hackers!!
I've bridged GitHub OAuth and SAML 2.0 together, and made it easy to use with a CLI (`npx saml-to --help`). It's called SAML.to (https://saml.to).
I've built this to be a no/low-cost alternative to using Okta, OneLogin, or JumpCloud for SAML Logins.
Using SAML.to, a configuration file is placed in a GitHub repository that defines one or many Service Providers and Permissions to GitHub users, then logging in is as simple as running a command in your console:
npx saml-to login
Or for role assumption (like IAM roles):
npx saml-to assume
I'd love this community's feedback on this, please let me know what you think!
Cheers, cnuss
CLI: https://github.com/saml-to/cli Forums: https://github.com/saml-to/cli/discussions Documentation: https://docs.saml.to
I've bridged GitHub OAuth and SAML 2.0 together, and made it easy to use with a CLI (`npx saml-to --help`). It's called SAML.to (https://saml.to).
I've built this to be a no/low-cost alternative to using Okta, OneLogin, or JumpCloud for SAML Logins.
Using SAML.to, a configuration file is placed in a GitHub repository that defines one or many Service Providers and Permissions to GitHub users, then logging in is as simple as running a command in your console:
npx saml-to login
Or for role assumption (like IAM roles):
npx saml-to assume
I'd love this community's feedback on this, please let me know what you think!
Cheers, cnuss
CLI: https://github.com/saml-to/cli Forums: https://github.com/saml-to/cli/discussions Documentation: https://docs.saml.to
Very cool! Are there any security concerns about having that config file checked into a GitHub repo?
great question yodon!
generally speaking, no, there should be no security concerns checking this into a repo but some best practices would be recommended to follow: - make the repo private - protect the main branch - require PRs and # approvals and/or add CODEOWNERS - only allow individuals that need to edit with write/admin privileges - having anybody with read-only access to the repo is unnecessary since SAML.to does the reading on behalf of the users
if provisioning is needed, there would be a encrypted token for SCIM in the text of the file, but that token is encrypted by SAML.to AWS KMS, so checking an encrypted string into a file shouldn't be a huge concern for most
also, SAML.to Premium allows users to maintain their own PKI and allows administrators to encrypt and sign according to their organizations requirements!
on a final note, I'd entertain a feature request for "include" statements in the config file so CODEOWNERS could be leveraged nicely
that's all I can think of for now. I'll get these best practices into the docs and I'd entertain any and all suggestions or thoughts!
generally speaking, no, there should be no security concerns checking this into a repo but some best practices would be recommended to follow: - make the repo private - protect the main branch - require PRs and # approvals and/or add CODEOWNERS - only allow individuals that need to edit with write/admin privileges - having anybody with read-only access to the repo is unnecessary since SAML.to does the reading on behalf of the users
if provisioning is needed, there would be a encrypted token for SCIM in the text of the file, but that token is encrypted by SAML.to AWS KMS, so checking an encrypted string into a file shouldn't be a huge concern for most
also, SAML.to Premium allows users to maintain their own PKI and allows administrators to encrypt and sign according to their organizations requirements!
on a final note, I'd entertain a feature request for "include" statements in the config file so CODEOWNERS could be leveraged nicely
that's all I can think of for now. I'll get these best practices into the docs and I'd entertain any and all suggestions or thoughts!