<div dir="ltr">Thanks Scott,<div><br></div><div>As it happens, eduPersonEntitlement is exactly what I proposed in the first place; and of course I could build and release an appropriate ePE in the IdP but only if I have the supervisor value available to me in the directory/attribute store, and the only option offered to me (unless I make a stand) is for HR to put in into eduPersonAffiliation in the directory.<br><br>I guess I could get the 'supplemented' ePA values, create the entitlement if the 'supervisor' value is there, and then remove any non-conforming values so the ePA as released by my IdP remains correct. I guess....<div><br></div><div>db</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Aug 25, 2025 at 4:33 PM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> To be more explicit, the constraint is HR's population of<br>
> 'supervisor' into the directory that is the issue: they already<br>
> populate conforming ePA values and can add the<br>
> 'supervisor' value as part of the routine sync to the record<br>
> of users who are supervisors, but they do NOT want to<br>
> revise or add a new process to populate the value to a<br>
> different attribute in AD.<br>
<br>
It's your directory. It doesn't follow that you have to produce such an Attribute out of a SAML IdP. Just turn it into an entitlement.<br>
<br>
-- Scott<br>
<br>
<br>
</blockquote></div>