<br /><br /><span>On 23/02/12, <b class="name">Chad La Joie </b> &lt;lajoie@itumi.biz&gt; wrote:</span><blockquote cite="mid:CACTY7uA9h6CkvkyOhxsFW6tbaAkcFaP+xBQhwOH4_=YEx6mAFw@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text plain">On Thu, Feb 23, 2012 at 06:11, Keith Carr &lt;kecarr@sgul.ac.uk&gt; wrote:<br />&gt; Decide locally how you're going to store grant information for any<br />&gt; random service.  I'm an LDAP kinda guy so I'd do it there.  Scott's a<br />&gt; database guy so he'd do it there.  But wherever you do it, just be<br />&gt; clear that what you're doing is store a grant to a particular service<br />&gt; because a specific user has access to that service.  Don't try to<br />&gt; infer it from some other potentially correlated data.<br />&gt;<br />&gt; If I understand you correctly I think it's this I'm trying to do:<br />&gt; - Ascertain from LDAP which franchise to which the user belongs.<br />&gt; - Then look up in the database whether the franchise to which the user<br />&gt; belongs has access to the resource (SP) being requested.<br />&gt; Have I understood correctly?<br /><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.</div></blockquote>I'm not sure I understand what you mean? What do you mean by look up entitlements?<br /><blockquote cite="mid:CACTY7uA9h6CkvkyOhxsFW6tbaAkcFaP+xBQhwOH4_=YEx6mAFw@mail.gmail.com" 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 />The reason for this is that eventually (and probably sooner rather<br />than later) you'll start running in to exception to the fuzzy logic<br />you're trying to use to determine entitlement.</div></blockquote>Surely this isn't fuzzy logic?<br />-Look up the user's group<br />-Determine if the group has access to the resource requested<br />if (the group has access to the resource) {<br />  give permitted value to the user's eduPersonAffiliation attribute<br />} else {<br />  do not give a value to the user's eduPersonAffiliation attribute<br />}<br /><br /><blockquote cite="mid:CACTY7uA9h6CkvkyOhxsFW6tbaAkcFaP+xBQhwOH4_=YEx6mAFw@mail.gmail.com" class="iwcQuote" style="border-left: 1px solid rgb(0, 0, 255); padding-left: 13px; margin-left: 0pt;" type="cite"><div class="mimepart text plain">And as soon as you do,<br />you end up having to put a new set of logic in place.  And then when<br />the next exception comes along you have to put a new set of logic in<br />place.  etc.  So, if you start by treating<br />grants/privileges/entitlements as first level concepts and track them<br />as such, you're not going to run in to issues (and it'll be slightly<br />more efficient when actually have to look up the data).</div></blockquote>Can you explain (in a simple way) how you would achieve what I am trying to accomplish?<br /><br />-Keith<br /><blockquote cite="mid:CACTY7uA9h6CkvkyOhxsFW6tbaAkcFaP+xBQhwOH4_=YEx6mAFw@mail.gmail.com" 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 />-- <br />Chad La Joie<br />www.itumi.biz<br />trusted identities, delivered<br />--<br />To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br /></div></blockquote>