[cnuss]

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

[yodon]

Very cool! Are there any security concerns about having that config file checked into a GitHub repo?

[cnuss]

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!