3rd Party SSO Login with Custom Group Management

14 replies
Last updated: Sep 24, 2020
Has anyone here successfully done 3rd-party SSO login with custom group management in Sanity?
We've gotten this all working -- groups are created with grants, users are added to the groups on login, and we do the tokenized claim to generate a Sanity session.

It works with one big problem, studio content is not editable. Every change is rejected with

Insufficient permissions; permission "create" required
.
I'll post more detail in the thread.
Aug 13, 2020, 10:23 PM
I've tried tokenizing the Sanity claim using both
administrator
and
editor
, which are the only two options according to the docs.
Our custom groups are called
'admin'
and
'editor'
. Here's what the
admin
one looks like:

{
  "_createdAt": "2020-08-12T00:09:18Z",
  "_id": "_.groups.admin",
  "_rev": "yUhunRJNe7KBgGINQx9Qma",
  "_type": "system.group",
  "_updatedAt": "2020-08-12T00:13:28Z",
  "grants": [
    {
      "path": "*",
      "permissions": [
        "read",
        "update",
        "create"
      ]
    }
  ],
  "members": [
    "e-039d58308f4cbc25635178c21176e4a06c88bfc7a3c93d049de3cb1002d379cb",
    "e-5061aa6c7adf886f28c27be5ed9242c8578908333663806ba4fca2927a32d394"
  ]
}
Note the full permissions. At least the way I'm reading the docs,
"path": "*",
is supposed to grant access to everything? Or do I need additional filters to make it work?
Aug 13, 2020, 10:31 PM
BTW shout out to
user Y
-- I used the Community Studio project as a reference point in how I wrote mine, which has gotten me really far! Let me know if you can think of any gotchas that might be causing this issue, thanks!
Aug 13, 2020, 10:33 PM
Aug 13, 2020, 11:48 PM
Hi
user R
Do you have custom access control activated on your plan? SSO is usually an enterprise feature that needs to be activated before you get access to the
create
permission
Aug 14, 2020, 8:47 AM
user J
yes, Enterprise
Aug 14, 2020, 3:51 PM
Hi
user R
! The path
*
actually only refers to documents with no prefixed path, ie
abcdef
, so the path
**
will also include
drafts.abcdef
. When you try to edit or create a new document in the Studio, whats actually being created is a draft
Aug 14, 2020, 4:11 PM
This is a little unintuitive, so I understand your confusion 🙂 Path expressions are defined here
https://www.sanity.io/docs/ids
In path expressions, * is taken to mean "anything up to the next period", while ** means "anything including periods".
The gotcha is, again, that creating a new document means a
draft.
prefiix, which wont match
*
, and the solution should be to change it to
**
for the path value in your grant
Aug 14, 2020, 4:13 PM
Cool thanks
user H
!
Aug 14, 2020, 4:22 PM
Np. Suggest looking into the
filter
property instead of
path
if you need more fine grained control over grants. You can achieve the same with
"grants": [
    {
      "filter": "_id in path('**')",
      "permissions": [
        "read",
        "update",
        "create"
      ]
    }
  ],
for example, but also add any other groq filter in there (except reference joins
->
)
Aug 14, 2020, 4:25 PM
Gotcha. Thanks. I think the doc that threw me off was https://www.sanity.io/docs/access-control#group-documents-c661fcf2c86c — path: *“**” is so commonly used to mean “anything” in the world at large that I assumed it did here as well.
Aug 14, 2020, 4:31 PM
I can definitely empathize with that, and I’ll bring this feedback to the docs team! Thank you Moses, and hope you get your access control under control 🙂
Aug 14, 2020, 5:15 PM
user R
,We've gone much of the same path as you and solved many of the same problems around granting access. We haven't gotten to the SSO part yet, though, so if you have anything to share with the experience you have now, it would be great.
Aug 15, 2020, 12:18 PM
user E
Sorry I didn't get back to you with more general info, but for the most part we followed the several example apps out there including the Community Studio project on Github, and followed the Sanity docs, to achieve Sanity login after we did 3rd-party SSO authorization. In our case we are using Vercel as our host, which has built-in serverless api routes, so I have sanity's login config direct to our /api/login route which makes the SSO call and provides a second route as the handler. I was able to successfully leverage the nextjs-auth0 library to do this serverside without needing to include nextjs as a peer dep. Auth0 is meanwhile working on upgrading their libs to be a bit more generic and avoid the confusion of needing to use something labeled 'nextjs' when really it works fine with just Vercel.
Sep 10, 2020, 6:04 PM
Thank you for this! 🙂
Sep 24, 2020, 2:09 PM

Sanity.io – build remarkable experiences at scale

Sanity is a customizable solution that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.