<div dir="ltr">Heh, yeah, well, as a stop-gap, here comes eduPersonEntitlement and a Scripted Attribute. Same idea, except you have the IdP plug-in to the source systems, build up the logic in the IdP & then express the authorization as an eduPersonEntitlement. Once you get Grouper to prod, you then convert your entitlement logic into grouper group-logic and then switch ePE into a Mapped Attribute whereby grouper groups now map to the old entitlement values. You then can decide what to do from there (isMemberOf vs additional entitlements).<div>
<br></div><div>Dave</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 7, 2013 at 10:17 AM, Bryan E. Wooten <span dir="ltr"><<a href="mailto:bryan.wooten@utah.edu" target="_blank">bryan.wooten@utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Yes Grouper, that is why it is my number 1 priority to get rolled out! Well, right after we fix our password policies for compliance, roll out MFA for switches and routers and PCI compliance and the MFA pilot for the NSTIC grant…</div>
<div><br>
</div>
<div>-Bryan</div>
<div><br>
</div>
<span>
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">
<span style="font-weight:bold">From: </span>David Langenberg <<a href="mailto:davel@uchicago.edu" target="_blank">davel@uchicago.edu</a>><br>
<span style="font-weight:bold">Reply-To: </span>"<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>" <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>><br>
<span style="font-weight:bold">Date: </span>Saturday, September 7, 2013 10:09 AM<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>" <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>><div class="im">
<br>
<span style="font-weight:bold">Subject: </span>Re: Can a single SP front multiple disparate applications?<br>
</div></div>
<div><br>
</div>
<div>
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br><div><div class="h5">
<br>
<div class="gmail_quote">On Sat, Sep 7, 2013 at 9:55 AM, Bryan E. Wooten <span dir="ltr">
<<a href="mailto:bryan.wooten@utah.edu" target="_blank">bryan.wooten@utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>><br>
><br>
><br>
>That is normal. Shibboleth doesn't care anything about eduPerson, those<br>
>are just defaults.<br>
><br>
>Curious to hear what those attributes they want are though, in my<br>
>experience there isn't much that isn't usually mappable to eduPerson or<br>
>other standard LDAP schemas that is commonly requested.<br>
><br>
>-- Scott<br>
<br>
</div>
We get requests for all kinds of attributes, some reasonable some make you<br>
scratch your head. Many want things like dept id or or org id or<br>
enrollment in a particular class / major or "chart field" (for billing<br>
purposes). We have one app that needs to know whether or not a student<br>
lives in campus housing.<br>
<br>
Then there is the request by one dept to have a student's complete<br>
historical record of majors / enrollments available via LDAPŠ.<br>
</blockquote>
<div><br>
</div>
<div>Here's where your Grouper installation comes to your rescue. Some of the time, yes, their app needs the attribute and in those cases we do create and release the attributes. However, often when you engage them in a dialog about why they need "enrolled
in HIST-247" attribute it boils down to them just needing a flag that says "authorized for app X" and all the various attributes they're requesting are really so they can make the computation of "authorized for app X". The paradigm we follow over here is
to create a group-structure for that app and then utilize grouper to build the "authorized for app X" group along with app-specific permission groups. We then push those to LDAP & have a shib shib just pass isMemberOf over. In this example I'd have a group
"uc:applications:history:authorized" and the group "uc:reference:students:enrollment:autumn2013:history:247" a member of :authorized. </div>
<div><br>
</div>
<div>Dave</div>
<div><br>
</div>
</div>
-- <br>
David Langenberg
<div>Identity & Access Management</div>
<div>The University of Chicago</div>
</div></div></div>
</div>
</div>
</div>
</span>
</div>
<br>--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>David Langenberg<div>Identity & Access Management</div>
<div>The University of Chicago</div>
</div>