GitHub access control

[Schwendner, Joanne]

Thank you James.

We have been using GitHub for quite a few months now, and have users in
there already, so we're probably past the point of provisioning this.  We
will have to work with what we have --  SSH keys, repos, and all.  Yes, we
would want to deny their SAML auth.

BTW that SCIM link is not working for me for some reason...

Joanne


On Wed, Jul 15, 2020 at 5:32 PM James Oulman <oulman at ufl.edu> wrote:

> We have been looking at this a bit and Github seems to want to use SCIM to
> automate invitations into Organizations. Unfortunately, the one that we
> have available AzureAD does not support AzureAD as the SCIM provider and a
> direct integration with Shibboleth. You get a “Unsupported IdP” error when
> you try to go through the set up. They seem to want you to use their
> application integration in the Azure AD marketplace (or whatever it’s
> called these days).
>
>
>
>
> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-scim
>
>
>
> Since our AzureAD SSO is uses ADFS, and our ADFS uses Shibboleth as a
> claims provider trust, we’ll probably just go the native AzureAD route.
> From there we can synchronize Github Org memberships with AD Groups.
>
>
>
> Is your desire to leave them as a member of the Org but deny their SAML
> auth? What about SSH keys, API access, etc.?
>
>
>
> *From: *users <users-bounces at shibboleth.net> on behalf of "Schwendner,
> Joanne" <joanne_schwendner at brown.edu>
> *Reply-To: *Shib Users <users at shibboleth.net>
> *Date: *Wednesday, July 15, 2020 at 2:03 PM
> *To: *"users at shibboleth.net" <users at shibboleth.net>
> *Subject: *GitHub access control
>
>
>
> *[External Email]*
>
> 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://wiki.shibboleth.net/confluence/x/coFAAg
> 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/20200720/6f93fb1a/attachment.htm>