Docusign authorization

[Paul B. Henson]

> From: Lipscomb, Gary
> Sent: Wednesday, November 29, 2017 5:02 PM
> 
> If you have an attribute e.g.  they are in a specific group, or
> docusignallowed=yes, that you can use to determine whether a use can
> access the app then an intercept flow is one solution.

I'm using a group in the attribute release policy to determine what attributes to release. Adding a whole flow just to special case this one service seems a bit heavyweight/kludgy?

I'm wondering if the other shib users Docusign is referring to actually did do something on the idp side or are just living with the goofy error on the Docusign side 8-/.

Thanks...

> > -----Original Message-----
> > From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Paul B.
> > Henson
> > Sent: Thursday, 30 November 2017 11:46
> > To: Shib Users <users at shibboleth.net>
> > Subject: Docusign authorization
> >
> > We recently integrated single sign-on with Docusign, and are having a bit of
> > an issue with the way they want to do authorization. Per their
> > documentation, if a user should not have access, the idp "should deny its
> > access by rejecting the SAML authentication request for that user". From
> the
> > perspective of a shibboleth idp, I'm not really sure what they are looking
> for;
> > for every other service we have the idp either fails to authenticate the
> user,
> > or if it succeeds in authentication it passes the user onto the service with
> > whatever attributes are configured for that relying party.
> >
> > Right now, a user shows up at Docusign and either has the necessary
> > attributes and successfully uses the service, or does not have the
> necessary
> > attributes and gets a very confusing error saying there is a configuration
> > problem with releasing attributes. According to Docusign, if we don't want
> a
> > user to access the service, we should not send them to the service from
> the
> > idp. On all of our other services, the authorization decision (as opposed to
> > attribute release policy) is made at the service, and the service provides
> the
> > appropriate authorization denied page, or a redirect to an appropriate
> > authorization denied page on one of our campus web servers.
> >
> > Docusign says they have clients using Okta and ADFS that are doing this
> > authorization on the idp side, as well as at least a few clients using
> > shibboleth. I asked how it worked, and they say that Okta gives a generic
> 401
> > or 403 error, and ADFS gives a classic Microsoft undecipherable error page
> > with a GUID or something on it. That just moves the confusing unhelpful
> > error message from one side to the other 8-/.
> >
> > They weren't sure what the clients using shibboleth were doing. Has
> anyone
> > worked with Docusign? If so, how are you handling this authorization issue?
> >
> > Thanks...
> >
> > --
> > Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
> > Operating Systems and Network Analyst  |  henson at cpp.edu California
> State
> > Polytechnic University  |  Pomona CA 91768
> >
> >
> > --
> > 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
> --
> 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