Can a single SP front multiple disparate applications?

[Bryan E. Wooten]

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<mailto:davel at uchicago.edu>>
Reply-To: "users at shibboleth.net<mailto:users at shibboleth.net>" <users at shibboleth.net<mailto:users at shibboleth.net>>
Date: Saturday, September 7, 2013 10:09 AM
To: "users at shibboleth.net<mailto:users at shibboleth.net>" <users at shibboleth.net<mailto: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<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130907/b1a3cdee/attachment.html