Shibboleth Developers

[Gregory Haverkamp <>]

On Thu, Aug 26, 2010 at 5:28 PM, Chad La Joie <> wrote:

Just so I know, Which features in particular?  So I know what we're balancing choices against.

In order from highest preference to lowest:

- Conditionally disabling SSO based on user input or IP  (but unless I'm underestimating the work, this may be my most obtainable today on my own with two LoginHandlers)

- Relying party config option for list of allowed auth methods

- Conditional evaluation of attribute defs/data connectors

- Moving login form and error outside of idp.war  (very minor thing; right now, I just 'cvs update; ./install.sh' on each of my IdPs when I update)

I'm sure it comes down to uses.  I'm rolling out Shibboleth not only for federation, but also web SSO for apps that will never need federation, where the latter will likely be my biggest consumer of Shibboleth services going forward.  As a result, I'm biased in that way.

Preference for IdP features over SP comes mainly from our predominant application deployment infrastructure, which is largely split between very fat Tomcat installations and .NET installations.  Java SP doesn't serve the latter, and the filter approach is a lot of pain for the former. But IdP enhancements serve all of them, as well as federated relying parties.

Greg