Deny user to access SP via IdP?

[Mark K. Miller]

On Thu, 12 Jun 2014, Ian Rifkin wrote:

> Hi,

Hi Ian,

> I run a Shib IdP and I get the difference between authentication and
> authorization, but unfortunately not every vendor I work with has this
> understanding.

I see that Brandeis is one of the 436 Higher Ed participants currently 
listed on the InCommon participants page.  Please use the influence of 436 
Higher Education institutions any time you're working with a vendor that 
other InCommon members may also deal with.

In this case, help them understand where the authorization decision 
belongs.  And, when they say it's too much effort just for you, show them 
the InCommon participants list and help them understand the effort is for 
everyone in the list!

> One vendor recently stated their expectation that we would only be sending
> people to their application if they should have access!

They are one vendor expecting it that way.  We are 436 Higher Education 
institutions execting it a different way.  Ian, make our case; help them 
get it right!

>                                                          My understanding is
> that I'm doing authentication and can give the SP whatever info they need to
> make authorization decisions --  many SPs understand this, but apparently
> not all.

The ones that don't get it are the ones we need to help.

> My question is if it's possible for the IdP to do some kind of authorization
> for specific SPs?

*ANYTHING* is possible, but don't do it!  Remember when vendors used to 
pitch 'single sign on' by uploading all our passwords to their 
application?  Sure, it's possible!  I hope you never did the password 
thing just because a vendor said that's how they do it.  ;-)

Enough of "Max's soapbox" for this reply.  Thanks to all who have 
listened,

Max

> I see that I can make filters to deny attributes based on the value of
> another attribute like so:
>             <afp:AttributeFilterPolicy>
>               <afp:PolicyRequirementRule
>             xsi:type="basic:AttributeValueString"
>             attributeID="someAttribute" value="someValue" />
>                 <afp:AttributeRule
>             attributeID="someOtherAttribute">
>                   <afp:DenyValueRule xsi:type="basic:ANY" />
>                 </afp:AttributeRule>
>                 <afp:AttributeRule
>             attributeID="someOtherOtherAttribute">
>                   <afp:DenyValueRule xsi:type="basic:ANY" />
>                 </afp:AttributeRule>
>             ?
>             </afp:AttributeFilterPolicy> 
> 
> This is close, but it's still directing the user to the SP (just not with
> much info about them). If I try this against my test SP or against
> sp.testshib.org the auth to the SP still "works". I think the SP doesn't get
> any real identifying info about the user, except for the IP, but it's still
> a successful authentication to the SP.
> 
> FYI, this matters for things like license agreements with vendors that we're
> paying for X number of seats or paying for a specific type of user to have
> access. Some vendors take the correct approach and look at an attribute like
> eduPersonScopedAffiliation, but alas not every vendor will do so.
> 
> Is it possible to not send anything back to the SP for users that match a
> PolicyRequirementRule (for a given SP / AttributeRequesterString)?
> 
> Or even better?is it possible to redirect a user to a URL of my choosing if
> the they match the criteria -- basically not sending them (back) to the SP
> unless they "should" have access to it.
> 
> I imagine this is a bit?unconventional?but I would appreciate if anyone has any
> insight.
> 
> Thanks,
> Ian
> 
> --
> Ian Rifkin
> Software Systems Manager
> Library and Technology Services (LTS)
> Brandeis University
> 
> http://go.brandeis.edu/u:irifkin
> 
>