Franchise access being authenticated by our Shibboleth IdP

[Keith Carr]

On 23/02/12, Chad La Joie  <lajoie at itumi.biz> wrote:
> You don't have to get them to agree on anything (lord knows most SPs
> won't anyways).
> 
> Decide locally how you're going to store grant information for any
> random service.  I'm an LDAP kinda guy so I'd do it there.  Scott's a
> database guy so he'd do it there.  But wherever you do it, just be
> clear that what you're doing is store a grant to a particular service
> because a specific user has access to that service.  Don't try to
> infer it from some other potentially correlated data.
> 
If I understand you correctly I think it's this I'm trying to do:
- Ascertain from LDAP which franchise to which the user belongs.
- Then look up in the database whether the franchise to which the user belongs has access to the resource (SP) being requested.
Have I understood correctly?

> 
> 
> Once you get that, then you can talk with each SP to see what
> attribute they want you to send and what value they want.  You can use
> the IdP to lookup the data, name it whatever the SP wants, munge the
> value to whatever they want, and send int.
> 
This is where I was sort of hoping that given the above and it having been determined that the user is entitled to access the resource or not (because of their LDAP attribute and using that to look up whether that group have access using the database); that I could then provide the "eduPersonAffiliation" attribute with one of the permitted values (if they are entitled access) or not.
I can appreciate that I'm probably not looking at using the best attribute to use by contemplating "eduPersonAffiliation".

Thanks for your help in this,
-Keith

> 
> 
> Now, if over time you *can* get the SPs to agree to a single attribute
> or a consistent value structure that will make your configuration
> simpler.  But until then, you can just do data munging.
> 
> On Wed, Feb 22, 2012 at 20:34, Keith Carr <kecarr at sgul.ac.uk> wrote:
> >
> > On 22/02/12, "Cantor, Scott" <cantor.2 at osu.edu> wrote:
> >
> >> A Query would be performed on the database using a data connector for the
> >> requesting resource and values returned for all the franchises. Each
> >> franchise "field" returned from the query would be put into an attribute
> >> (FRANA_GRANTED and FRANB_GRANTED). This would then be assessed
> >> along with the "shibbolethset" attribute to determine whether the user
> >> should be given a eduPersonAffiliation attribute value which will grant
> >> access
> >> to the resource.
> >
> > That's a fundamental problem. Affiliation is not based on whether you have
> > access to a resource, it's a fact of the identity involved independent of
> > any resource. It's a very bad idea to conflate that.
> >
> > -- Scott
> >
> > Hi Scott,
> > I agree, however I'm failing to see another way to accomplish the task I
> > have been set.
> > In an ideal world I'm guessing that I would set some values for
> > eduPersonEntitlement indicating whether the user was allowed acces to the
> > resource and agree these with the SP's?
> > The problem I can see in this is getting all the SP's to organise and agree
> > these within the time-frame.
> > Is there another way in which I should be attacking this?
> >
> > - Keith
> >
> >
> >
> > --
> > To unsubscribe from this list send an email to
> > users-unsubscribe at shibboleth.net
> >
> >
> > --
> > To unsubscribe from this list send an email to
> > users-unsubscribe at shibboleth.net
> 
> 
> 
> -- 
> Chad La Joie
> www.itumi.biz
> trusted identities, delivered
> --
> 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/120df404/attachment.html