<br /><br /><span>On 23/02/12, <b class="name">Keith Hazelton </b> <hazelton@doit.wisc.edu> wrote:</span><blockquote cite="mid:B1D8FB49-FA48-4B9A-BACD-65B28DBD1AFE@doit.wisc.edu" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text html"><span><p><table><tbody><tr><td style="word-wrap: break-word;"><p></p><div><div>On Feb 23, 2012, at 10:26, Keith Hazelton wrote:</div><br class="Apple-interchange-newline" /><blockquote type="cite"><div style="word-wrap: break-word;"><div><div>On Feb 23, 2012, at 10:15, Keith Carr wrote:</div><br class="Apple-interchange-newline" /><blockquote type="cite"><br /><br /><span>On 23/02/12, <b class="name">Peter Schober </b> <<a href="mailto:peter.schober@univie.ac.at">peter.schober@univie.ac.at</a>> wrote:</span><blockquote cite="mid:20120223123832.GT22863@wssp.cc.univie.ac.at" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text plain">* Keith Carr <<a href="mailto:kecarr@sgul.ac.uk">kecarr@sgul.ac.uk</a>> [2012-02-23 13:25]:<br />> > No. Don't try to imply entitlement. The user either has it, or they<br />> > don't. So, go to the directory or database, look up entitlements.<br />> > Done.<br />> > <br />> I'm not sure I understand what you mean? What do you mean by look up<br />> entitlements?<br /><br />My interpretation would be to take that literally and lookup a users<br />entitlements (e.g. common-lib-terms) from a directory service or an<br />RDBMS and use those "as is" in the IdP. (Assuming access is granted to<br />the SP based on an entitlement).</div></blockquote>Ahhh, I understand. I do store the user's entitlement in LDAP (e.g; "student" or "staff") and this is supplied to the resource. I guess the answer would be to have a new entitlement given to the franchised users (e.g. "franchise") and to those resources that they have access, add it to the list of entitlements they accept?<br />-Keith<br /></blockquote><div><br /></div><div>It would help this conversation if we could agree to use the terminology from the eduPerson specification:</div><div><br /></div><div>student and staff etc. are affiliations.</div><div><br /></div><div>common-lib-terms is an example entitlement</div><div><br /></div><div>Here at UW-Madison we manage all this by associating a list of entitlements with an affiliation. So "students" get entitlements to email, calendar, wiki, library, rec. sports, etc.</div><div><br /></div><div>We "flatten" this in our LDAP and in our SAML assertions via business logic: That is, if Jane Swift is a student, then attributes in LDAP and/or SAML attribute assertions might include:</div><div><br /></div><div>eduPersonGivenName: Jane</div><div>eduPersonSurname: Swift</div><div><br /></div><div>eduPersonScopedAffiliation: student</div></div></div></blockquote><div><br /></div><div>that should read eduPersonScopedAffiliation: <a href="mailto:student@wisc.edu">student@wisc.edu</a></div><br /><blockquote type="cite"><div style="word-wrap: break-word;"><div><div><br /></div><div>eduPersonEntitlement: email</div><div><div>eduPersonEntitlement: calendar</div><div><div>eduPersonEntitlement: wiki</div></div><div><div>eduPersonEntitlement: library</div></div><div><div>eduPersonEntitlement: recreationalSportsFacilities</div></div><div>...</div><div><br /></div><div>How does that line up against your case?</div></div></div></div></blockquote></div></td></tr></tbody></table></p></span></div></blockquote>Hi (other) Keith,<br />That makes sense. Do you "flatten" the entitlements to one attribute value in ldap or one in each of a multi-vlaued attribute?<br /><br />However in our case it's tricky. As I stated to Chad:-<span style="font-family: monospace;"><br /></span>"Franchise A" always have access to SP 1, SP 2 and SP 3 and nothing else.<br />"Franchise B" always have access to SP 1, SP 2 and SP 4 and nothing else.<br /><br />So I would need to "share" a new entitlement with our SP's in order to differentiate the new franchise.<br /><br />-Keith<br /><blockquote cite="mid:B1D8FB49-FA48-4B9A-BACD-65B28DBD1AFE@doit.wisc.edu" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text html"><span><p><table><tbody><tr><td style="word-wrap: break-word;"><div><blockquote type="cite"><div style="word-wrap: break-word;"><div><div><div ><br/></div><div><br /></div><div> --Keith Hazelton (<a href="mailto:hazelton@wisc.edu">hazelton@wisc.edu</a>)</div><div><br /></div></div><br /><blockquote type="cite"><blockquote cite="mid:20120223123832.GT22863@wssp.cc.univie.ac.at" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text plain"><br /><br />That's pretty close to what I said before when if I'd be creating<br />such a system from scratch, to base it on the individual user(s).<br />It'll also avoid implementing logic (and the inevitable exceptions) in<br />the IdP, as all the logic (who gets access to what) needs to be<br />implemented when storing those values somewhere in LDAP/an<br />RDBMS. Granted it still has to happen somewhere, but then it'd be OOB<br />and not involving the IDP at all. (Consider this "flattening" the<br />affiliations, entitlements and "franchise" groups to a list of users<br />and their services. Might also be useful for internally provided<br />services).<br />-peter<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></blockquote>
--<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 /></div>--<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 /></td></tr></tbody></table></p></span></div></blockquote>