Can a single SP front multiple disparate applications?

[David Langenberg]

Heh, yeah, well, as a stop-gap, here comes eduPersonEntitlement and a
Scripted Attribute.  Same idea, except you have the IdP plug-in to the
source systems, build up the logic in the IdP & then express the
authorization as an eduPersonEntitlement.  Once you get Grouper to prod,
you then convert your entitlement logic into grouper group-logic and then
switch ePE into a Mapped Attribute whereby grouper groups now map to the
old entitlement values.  You then can decide what to do from there
(isMemberOf vs additional entitlements).

Dave


On Sat, Sep 7, 2013 at 10:17 AM, Bryan E. Wooten <bryan.wooten at utah.edu>wrote:

>  Yes Grouper, that is why it is my number 1 priority to get rolled out!
> Well, right after we fix our password policies for compliance, roll out MFA
> for switches and routers and PCI compliance and the MFA pilot for the NSTIC
> grant…
>
>  -Bryan
>
>   From: David Langenberg <davel at uchicago.edu>
> Reply-To: "users at shibboleth.net" <users at shibboleth.net>
> Date: Saturday, September 7, 2013 10:09 AM
> To: "users at shibboleth.net" <users at shibboleth.net>
>
> Subject: Re: Can a single SP front multiple disparate applications?
>
>
>
>
> On Sat, Sep 7, 2013 at 9:55 AM, Bryan E. Wooten <bryan.wooten at utah.edu>wrote:
>
>> >
>> >
>> >
>> >That is normal. Shibboleth doesn't care anything about eduPerson, those
>> >are just defaults.
>> >
>> >Curious to hear what those attributes they want are though, in my
>> >experience there isn't much that isn't usually mappable to eduPerson or
>> >other standard LDAP schemas that is commonly requested.
>> >
>> >-- Scott
>>
>>  We get requests for all kinds of attributes, some reasonable some make
>> you
>> scratch your head. Many want things like dept id or or org id or
>> enrollment in a particular class / major or "chart field" (for billing
>> purposes). We have one app that needs to know whether or not a student
>> lives in campus housing.
>>
>> Then there is the request by one dept to have a student's complete
>> historical record of majors / enrollments available via LDAPŠ.
>>
>
>  Here's where your Grouper installation comes to your rescue.  Some of
> the time, yes, their app needs the attribute and in those cases we do
> create and release the attributes.  However, often when you engage them in
> a dialog about why they need "enrolled in HIST-247" attribute it boils down
> to them just needing a flag that says "authorized for app X" and all the
> various attributes they're requesting are really so they can make the
> computation of "authorized for app X".   The paradigm we follow over here
> is to create a group-structure for that app and then utilize grouper to
> build the "authorized for app X" group along with app-specific permission
> groups.  We then push those to LDAP & have a shib shib just pass isMemberOf
> over.  In this example I'd have a group
> "uc:applications:history:authorized" and the group
> "uc:reference:students:enrollment:autumn2013:history:247" a member of
> :authorized.
>
>  Dave
>
>  --
> David Langenberg
> Identity & Access Management
> The University of Chicago
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130907/ef71d159/attachment.html