<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Perhaps you should ask this vendor how, prior to SAML, they prevented “unauthorized” users from attempting access;<div>if they had a login button or URL, could they make that not appear or not work for some users without knowing anything</div><div>about that prospective user?</div><div><br></div><div><br></div><div><div><div>On Thu, 12 Jun 2014, at 08:32 , Ian Rifkin <<a href="mailto:irifkin@brandeis.edu">irifkin@brandeis.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div>Hi,<br><br></div><div>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.<br></div><br>
</div>One vendor recently stated their expectation that we would only be sending people to their application if they <i>should</i> have access! 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.<br>
<br></div>My question is if it's possible for the IdP to do some kind of authorization for specific SPs…<br><br></div>I see that I can make filters to deny attributes based on the value of another attribute like so:<br>
<blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><afp:AttributeFilterPolicy><br> <afp:PolicyRequirementRule xsi:type="basic:AttributeValueString" attributeID="someAttribute" value="someValue" /><br>
<afp:AttributeRule attributeID="someOtherAttribute"><br> <afp:DenyValueRule xsi:type="basic:ANY" /><br> </afp:AttributeRule><br> <afp:AttributeRule attributeID="someOtherOtherAttribute"><br>
<afp:DenyValueRule xsi:type="basic:ANY" /><br> </afp:AttributeRule><br>…<br></afp:AttributeFilterPolicy> </blockquote></blockquote><div><div>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 <a href="http://sp.testshib.org/">sp.testshib.org</a> 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.<br>
<br></div><div>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.<br>
</div><div><br></div><div>Is it possible to not send <i>anything</i> back to the SP for users that match a PolicyRequirementRule (for a given SP / AttributeRequesterString)?<br></div><div><br></div><div>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.<br>
<br></div><div>I imagine this is a bit…unconventional…but I would appreciate if anyone has any insight.<br></div><div><br></div><div>Thanks,<br>Ian<br></div><div><br>-- <br>Ian Rifkin<br>Software Systems Manager<br>Library and Technology Services (LTS)<br>
Brandeis University<br><br><a href="http://go.brandeis.edu/u:irifkin" target="_blank">http://go.brandeis.edu/u:irifkin</a>
</div></div></div>
--<br>To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a></blockquote></div><br></div></body></html>