Docusign authorization

[Lipscomb, Gary]

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.

> -----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