GitHub access control

Brian Moon bmoon at scu.edu
Wed Jul 15 18:12:32 UTC 2020


Hello Joanne,

It sounds like what you need is a "context-check" interceptor flow
<https://wiki.shibboleth.net/confluence/display/IDP30/ContextCheckInterceptConfiguration>.
With this flow, you can interrupt the authentication process and have the
IdP look at the SP being requested and then at some user attribute(s) to
decide whether to halt the flow or let it continue.  We use this for
controlling access to one of our SPs and it has made life a whole lot
easier.

Hope that helps!

Brian Moon
Senior System Administrator, Enterprise Systems
Santa Clara University


On Wed, Jul 15, 2020 at 11:02 AM Schwendner, Joanne <
joanne_schwendner at brown.edu> wrote:

> Does anyone have experience with controlling access to
> individual Organizations in GitHub Cloud?  We would like to control access
> by using Grouper group memberships.  We are successfully using their SAML
> SSO support.  But...
>
> It seems the only attribute GitHub cares about is NameID.  We are
> currently passing our persistent ID in NameID.  If it's there, they get in.
> To block access for a user, we would have to NOT send NameID in the
> assertion, if that's even possible.
>
> Is it possible to conditionally NOT send NameID depending on a user's
> other attributes?  Is there another way to manage GitHub Org access
> (besides manually)?
>
> Thanks.
> Joanne
>
> ---
>
> Joanne Schwendner
> Senior Developer - Web, Integration, & Identity Services
> Brown University
>
> --
> For Consortium Member technical support, see
> https://urldefense.com/v3/__https://wiki.shibboleth.net/confluence/x/coFAAg__;!!MLMg-p0Z!TkYOp7DK4febwUmzMBSD_h1dI7wP0QRmasfVrmAe3f2AzBUVX9rwc26wmlpY$
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200715/99c70122/attachment.htm>


More information about the users mailing list