Franchise access being authenticated by our Shibboleth IdP

[Keith Carr]

On 23/02/12, Peter Schober  <peter.schober at univie.ac.at> wrote:
> * Keith Carr <kecarr at sgul.ac.uk> [2012-02-23 02:28]:
> > Two different users in two separate notes/leaves of LDAP would only
> > tell you to which group of users the user belonged.
> 
> Based on what you write the granularity is "franchise", not individual
> users. So identifying the franchise based on "data"/"metadata" of the
> subject could replace the database tables, IMO.
> 
This is quite correct; granularity is based on "franchise" - but I am using an LDAP attribute to identify to which franchise they belong, not the database.

    <resolver:AttributeDefinition id="shibbolethset"
                                  xsi:type="Simple"
                                  xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                  sourceAttributeID="shibbolethset"
                                  dependencyOnly="true">

        <resolver:Dependency ref="myLDAP" />

        <resolver:AttributeEncoder xsi:type="SAML1String"
                                   xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="shibbolethset" />
        <resolver:AttributeEncoder xsi:type="SAML2String"
                                   xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="shibbolethset"
                                   friendlyName="shibbolethset" />
    </resolver:AttributeDefinition>

The database is used purely to identify if the particular "franchise" (group) has access to the resource being requested. So it is saying for a request for resource (SP) "1" franchise_a has access but franchise_b does not. Then for resource "2" franchise_a has access and so does franchise_b.

> 
> 
> > Since those two users (in separate notes/leaves) may or may not have
> > access to a particular resource (SP) I would have to write
> > JavaScript to assertain whether the notes/leaves had access to a
> > resource. Multiply this by ten, or one hundred resources (SP's) and
> > the JavaScript starts to become very hard to maintain due to it's
> > size.
> 
> That's why I mentioned the mapped attribute defintion. I would
> probably assign an attribute identifying the franchise in the script,
> 
This is what I was proposing with:

    <resolver:AttributeDefinition id="requestEnt"
                                  xsi:type="Simple"
                                  xmlns="urn:mace:shibboleth:2.0:resolver:ad"
                                  sourceAttributeID="requestEnt"
                                  dependencyOnly="true">

        <resolver:AttributeEncoder xsi:type="SAML1String"
                                   xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="requestEnt" />
        <resolver:AttributeEncoder xsi:type="SAML2String"
                                   xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                                   name="requestEnt"
                                   friendlyName="requestEnt" />

        <Script>
        <![CDATA[
            importPackage(Packages.edu.internet2.middleware.shibboleth.common.attribute.provider);
            if (requestEnt == null) {
                requestEnt = new BasicAttribute("requestEnt");
            }

            requester = requestContext.inboundMessageIssuer;
            requestEnt.getValues().add(requester);
        ]]>
        </Script>
    </resolver:AttributeDefinition>

> 
> and in a seperate attribute create all the necessary entitlements
> based on that franchise attribute. That's not expected to grow
> unweildly soon, as for each "SourceValue" (the franchise) you'll have
> several ReturnValues (e.g. entitlements or whatever), one per line.
> 
I'm not sure I understand what you mean here?

> 
> 
> Anyway I just though I'll mention the possibility of reusing existing
> information instead of setting up yet another repository of data that
> needs to be managed somehow (sync'ed from a SOR or providing
> management interfaces for the people managing contracts, etc.).
> 
Yes I totally agree - I would rather reuse existing information where it exists.

> 
> If I'd create such a system for grants/permissions I'd certainly
> want to design it to be granular to each netid/subject, and also
> factor group memberships and/or other organizational data into its
> (calculated) output. Just my 2¢.
> -peter
> 
Your input is much appreciated.
-Keith

> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120223/80d38d84/attachment-0001.html