<br /><span>On 23/02/12, <b class="name">Peter Schober </b> &lt;peter.schober@univie.ac.at&gt; wrote:</span><blockquote cite="mid:20120223082150.GQ22863@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 &lt;kecarr@sgul.ac.uk&gt; [2012-02-23 02:28]:<br />&gt; Two different users in two separate notes/leaves of LDAP would only<br />&gt; tell you to which group of users the user belonged.<br /><br />Based on what you write the granularity is &quot;franchise&quot;, not individual<br />users. So identifying the franchise based on &quot;data&quot;/&quot;metadata&quot; of the<br />subject could replace the database tables, IMO.</div></blockquote>This is quite correct; granularity is based on &quot;franchise&quot; - but I am using an LDAP attribute to identify to which franchise they belong, not the database.<br /><br />    &lt;resolver:AttributeDefinition id=&quot;shibbolethset&quot;<br />                                  xsi:type=&quot;Simple&quot;<br />                                  xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot;<br />                                  sourceAttributeID=&quot;shibbolethset&quot;<br />                                  dependencyOnly=&quot;true&quot;&gt;<br /><br />        &lt;resolver:Dependency ref=&quot;myLDAP&quot; /&gt;<br /><br />        &lt;resolver:AttributeEncoder xsi:type=&quot;SAML1String&quot;<br />                                   xmlns=&quot;urn:mace:shibboleth:2.0:attribute:encoder&quot;<br />                                   name=&quot;shibbolethset&quot; /&gt;<br />        &lt;resolver:AttributeEncoder xsi:type=&quot;SAML2String&quot;<br />                                   xmlns=&quot;urn:mace:shibboleth:2.0:attribute:encoder&quot;<br />                                   name=&quot;shibbolethset&quot;<br />                                   friendlyName=&quot;shibbolethset&quot; /&gt;<br />    &lt;/resolver:AttributeDefinition&gt;<br /><br />The database is used purely to identify if the particular &quot;franchise&quot; (group) has access to the resource being requested. So it is saying for a request for resource (SP) &quot;1&quot; franchise_a has access but franchise_b does not. Then for resource &quot;2&quot; franchise_a has access and so does franchise_b.<br /><blockquote cite="mid:20120223082150.GQ22863@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 />&gt; Since those two users (in separate notes/leaves) may or may not have<br />&gt; access to a particular resource (SP) I would have to write<br />&gt; JavaScript to assertain whether the notes/leaves had access to a<br />&gt; resource. Multiply this by ten, or one hundred resources (SP's) and<br />&gt; the JavaScript starts to become very hard to maintain due to it's<br />&gt; size.<br /><br />That's why I mentioned the mapped attribute defintion. I would<br />probably assign an attribute identifying the franchise in the script,</div></blockquote>This is what I was proposing with:<br /><br />    &lt;resolver:AttributeDefinition id=&quot;requestEnt&quot;<br />                                  xsi:type=&quot;Simple&quot;<br />                                  xmlns=&quot;urn:mace:shibboleth:2.0:resolver:ad&quot;<br />                                  sourceAttributeID=&quot;requestEnt&quot;<br />                                  dependencyOnly=&quot;true&quot;&gt;<br /><br />        &lt;resolver:AttributeEncoder xsi:type=&quot;SAML1String&quot;<br />                                   xmlns=&quot;urn:mace:shibboleth:2.0:attribute:encoder&quot;<br />                                   name=&quot;requestEnt&quot; /&gt;<br />        &lt;resolver:AttributeEncoder xsi:type=&quot;SAML2String&quot;<br />                                   xmlns=&quot;urn:mace:shibboleth:2.0:attribute:encoder&quot;<br />                                   name=&quot;requestEnt&quot;<br />                                   friendlyName=&quot;requestEnt&quot; /&gt;<br /><br />        &lt;Script&gt;<br />        &lt;![CDATA[<br />            importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);<br />            if (requestEnt == null) {<br />                requestEnt = new BasicAttribute(&quot;requestEnt&quot;);<br />            }<br /><br />            requester = requestContext.inboundMessageIssuer;<br />            requestEnt.getValues().add(requester);<br />        ]]&gt;<br />        &lt;/Script&gt;<br />    &lt;/resolver:AttributeDefinition&gt;<br /><blockquote cite="mid:20120223082150.GQ22863@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 />and in a seperate attribute create all the necessary entitlements<br />based on that franchise attribute. That's not expected to grow<br />unweildly soon, as for each &quot;SourceValue&quot; (the franchise) you'll have<br />several ReturnValues (e.g. entitlements or whatever), one per line.</div></blockquote>I'm not sure I understand what you mean here?<br /><blockquote cite="mid:20120223082150.GQ22863@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 />Anyway I just though I'll mention the possibility of reusing existing<br />information instead of setting up yet another repository of data that<br />needs to be managed somehow (sync'ed from a SOR or providing<br />management interfaces for the people managing contracts, etc.).</div></blockquote>Yes I totally agree - I would rather reuse existing information where it exists.<br /><blockquote cite="mid:20120223082150.GQ22863@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 />If I'd create such a system for grants/permissions I'd certainly<br />want to design it to be granular to each netid/subject, and also<br />factor group memberships and/or other organizational data into its<br />(calculated) output. Just my 2¢.<br />-peter</div></blockquote>Your input is much appreciated.<br />-Keith<br /><blockquote cite="mid:20120223082150.GQ22863@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 />To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br /></div></blockquote>