Simple Internal Federation Example?

[Todd Piket]

Scott,

Yes, it's the new filter policy syntax that got me, though I really like how it has evolved.  I've gotten a couple off list examples that have helped my brain begin transitioning from 1.3 to 2.x, which isn't a lot of change, as you mentioned, but there is some...all good of course.  I think some of the issue is language barrier as well.  What tags, attributes and values can be used in the XML.  That will come with reading and time though, now that I have a starting point.  Anyway, it seems I'm off and running.  I will definitely have to explore how best to do the attribute release policies for my setup, obviously, but having an example or two helps.

Thanks for the reply Scott and others.



Regards,

Todd Piket
Middleware Technical Architect

"We would accomplish many more things if we did not think of them as impossible."  -Vince Lombardi







>>> On Tue, Oct 4, 2011 at 11:29 AM, in message <CAB0AC11.10E0C%cantor.2 at osu.edu>,
"Cantor, Scott" <cantor.2 at osu.edu> wrote: 
> On 10/4/11 10:48 AM, "Todd Piket" <Todd.Piket at csu.mnscu.edu> wrote:
> 
>>All good points Peter.  I use the term "internal federation" to suggest
>>that this is for internal use only and is unlikely to be joined with any
>>other federation like InCommon.  The simple federation I'm getting at is
>>a single IdP with one or more SPs.  The IdP would have a specific
>>attribute release policy for one or more of the SPs.  Preferably
>>releasing attributes from an LDAP server.  I think the SP/IdP part isn't
>>what I'm struggling with, but the attribute release policy and filter
>>setup.  I'll keep cruising the wiki as well.  Maybe something will click
>>eventually.
> 
> I use a set of policies that group SPs by their attribute needs. Then I
> wrap all the SPs that get a particular set into an OR rule and name them.
> In a few cases, I do regexes.
> 
> There are an infinite number of ways to do it. You could create one policy
> per SP, which was typical in 1.3. You could create a policy per attribute
> and then list the SP in each policy for an attribute it should get.
> 
>>Also, I do see that the default config is mostly usable, but I find that
>>modifying it is far less intuitive than it used to be and I don't seem to
>>be connecting the dots using the information provided on the wiki.
>>Perhaps it is more difficult to boot strap a 2.x setup when you're
>>previous experience is with 1.3?  I don't know, but I built the 1.3
>>instance in about a day, but the 2.x instance isn't going as well.
> 
> I think you'd have to try and identify what was confusing. Largely it's
> identical in most respects except for the big one, authentication, and in
> the filter policy syntax, which is vastly more flexible and commensurately
> harder to learn.
> 
> -- Scott
> 
> --
> To unsubscribe from this list send an email to 
> users-unsubscribe at shibboleth.net