Thanks folks. Looks like there are two ways to achieve it:<br>1) - deploy separate login handlers<br>
- use an AuthnContextClassRef in the request to map to one or the other<br><br>2) IdP will always return both Eng and Sales people, the Assertion will contain some attribute to indicate the group. SP will need to do some authorization to filter out either Eng or Sales.<br>
<br>Per Scott and Kevin, (2) is a better way since IdP is only suppose to do authn, it is SP's responsibility to do authz. <br><br>Let me know if anything is incorrect.<br><br>Thanks,<br clear="all">Yaowen<br>
<br><br><div class="gmail_quote">On Thu, Aug 16, 2012 at 8:44 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 8/16/12 11:33 AM, "Yannick Béot" <<a href="mailto:yannick.beot@gmail.com">yannick.beot@gmail.com</a>> wrote:<br>
><br>
>I do not know much about Shibboleth IdP but I'm pretty sure it is<br>
>possible to insert some filtering/authz logic in the pipeline, based on<br>
>some attributes for instance.<br>
<br>
</div>If you write custom login handlers; there's nothing built-in to do this.<br>
It's just not how it's supposed to work.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br>