Add Osso as open source SAML provider #928
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/nextauthjs/next-auth/o6j1ymwq2 |
|
The intention IS to use canary as your base. This we can merge things faster and get them out to npm with a |
|
thanks... wasn't clear in the contribution guidelines that was the intention |
|
Sorry about that! We are currently transitioning to a new structure we started a few days ago. Hopefully, this will allow a faster release cycle for those who don't mind some bugs here and there. Once the details are set, we will probably update the CONTRIBUTING document. |
|
no problem! sorry bout it all, hate to create more work for maintainers. its a clever approach now that i understand a bit! anyhow, it feels like too big a change to find a way to add another query param to my authorize url based on user input? so we'll get cracking on more of a hosted sign in flow so I can at least demo this in action. It's a bit tough because in order to do a full SAML login you'll need an Osso instance (we have one at demo.ossoapp.com) and to have configured a SAML provider (Okta has a good developer account offering) in it, and assigned users, etc. |
src/providers/osso.js
Outdated
| return { | ||
| id: profile.id, | ||
| name: profile.name, | ||
| email: profile.email |
There was a problem hiding this comment.
we currently offer a minimal profile, but could envision adding more attributes as needed. can we ...spread the profile object? are any of these required?
There was a problem hiding this comment.
Great question! The docs on this could use improving.
To work with a database, a id is required from a profile, it is stored as accountId, but name and email are optional as neither are guaranteed from a provider.
From memory:
- If using a database then the
nameandemailwill be used when creating a new user, but if the account exists and is associated with a user, then it will use theidto look up the account, then from there look up theuserassociated with that account and return them for the user info whengetSession()is called. - If using JSON Web Tokens without a database, then it doesn't matter what these values are, but if blank they will be blank in the JSON Web Token / Session.
- The full profile returned from a provider is exposed in various callbacks. It is used here for very limited purposes. Returning extra fields here has no impact.
|
Our vercel teams trial expired, so the demo app for this is now at https://nextjs-demo.ossoapp.com/ lmk what i can do to push this along! more than happy to write docs etc, not sure what the expectation is for a canary merge 🙏 |
|
@sbauch I just wanted to say have checked out the demo site, thanks for setting that up. Osso looks really cool! Having a way to integrate with SAML auth directly would be a lot of work for something like NextAuth.js, so having an solution like this is wonderful, especially an open source product. It would be lovely to chat sometime! |
|
thanks @iaincollins! glad to hear you think this could be a good addition - it's admittedly a little weird to add support for a provider like this where the library users have to deploy or pay for an Osso instance, but since you already support a provider like Auth0 it seems reasonable to us. I'm planning on responding to feedback here and writing some docs this week, but would be happy to connect. to avoid putting my email on github, maybe you could drop a note in our chat widget at ossoapp.com and we can take it offline from there? |
| profile: (profile) => { | ||
| return { | ||
| id: profile.id, | ||
| name: profile.name || profile.email, |
There was a problem hiding this comment.
SAML spec is a little odd wrt NAMEID format things. Osso's docs don't instruct IDP admins to include a "name" attribute, but we do sometimes get them back.
I'm thinking here that if the database or user model depends on there being a name, we should at least fall back to email, which is guaranteed to be available.
|
Added some docs and got up to date here 📖 👩⚕️ 👨⚕️ |
|
added docs for this to our docs site (borrowing a bit from your docs) - https://ossoapp.com/docs/consume/nextjs now that the big release and security patch is out, chances we could take another look here? |
|
Hi there, and thanks for your patience on this! I think we are ready to approve this, only one thing left... I am going to close this PR, because we changed our release strategy, and this PR should be opened against |
Per #311 this adds a Provider Osso - we're like an open source Auth0, but exclusively for SAML 2.0.
Osso provides a UI, persistence and documentation for configuring SAML identity providers, and wraps a SAML auth process inside in Oauth 2.0 auth code grant flow, which allows us to easily hook in to projects like this that implement Oauth. You can check out a demo Osso instance at https://demo.ossoapp.com and generally learn more about osso at https://ossoapp.com
In order to show how this all works, I've set up the following:
• a staging instance of Osso
this includes some work to add a "hosted login page" like Auth0 has
• a next app - https://osso-next-auth-mcwe2rmtw.vercel.app/
this is based on this project's example, but includes a module transpilation plugin to build a version of this package with support for Osso as a provider. it uses the review Osso app above via ENV vars for
OSSO_DOMAIN,OSSO_IDandOSSO_SECRET. repo: https://github.com/enterprise-oss/osso-next-auth-example• a fake Identity Provider
It takes a bit of work to configure an IDP for SAML login, so we've developed a little ruby app that acts as a fake IDP. it takes a SAMLRequest, allows a user to "log in" using any values, and crafts a SAMLResponse, sending the user back to osso and eventually the next app on vercel. repo: https://github.com/enterprise-oss/sinatra-ruby-idp
So you can test this end to end:
I'll leave some code specific comments inline.
Thanks gang, and apologies again for my nonsense with the canary branch etc. Would be really excited to get support for Osso into such a great project!