Dealing with different sets of users

[Rob Whitener]

Thank you for the responses.  I figured it would be more of an app thing.
 I know that we are going to provide a specific url to trigger the initial
auth.  I was also thinking in terms of when the partner's users return to
our main site, but on the backend I think I can figure out which users
belong to which group and handle it appropriately.  I could see us, in the
future, needing to be an identity provider so I will explore that option as
well.  I will check out the SPBackDoor functionality as well, that actually
sounds like exactly what I need.

Thanks again,

Rob

On Wed, Jun 6, 2012 at 9:59 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 6/6/12 9:47 AM, "Rob Whitener" <rob.whitener at audaxhealth.com> wrote:
> >
> >My company is in the process of setting up Shibboleth to integrate with a
> >partner who uses SAML for auth.  The end goal is to have their users be
> >able to use our services (they are the identity provider and we are the
> >service provider).  However, we will
> > still have another large set of users who authenticate directly to us
> >and there is no need for SAML.  Is there any way in the configuration of
> >shibboleth to account for this or will I need to make the application
> >itself account for this?
>
> It isn't directly supported (it couldn't be). There are a handful of
> options:
>
> - stick an IdP in front of those other users to consolidate everything
> behind one abstraction (this is the best option, because it leads to the
> right UI)
>
> - do it in the application
>
> - 2.5 adds a new capability for integration with external authentication,
> it's in the wiki now, search for SPBackDoor
>
> -- Scott
>
> --
> 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/20120606/e014c7b1/attachment.html