Some thoughts about Shibboleth (from a deployer point of view)

[Youssef GHORBAL]

> On 10 Apr 2016, at 20:00, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> I’ve deployed a lot of software in my career (Open Source or not),
>> what strikes me with Shibboleth is the proxmity or, if I may say, the fusion
>> between the sotware technology (languages, frameworks) used to make the
>> software and the configuration of the said software.
> 
> Using Spring essentially necessitates that unless you have the kind of resources required to build and maintain a layer in between (and in the process give up a ton of the flexibility Spring offers). We don't have the people or skill sets to do that well even if we wanted to, and I personally don't, because I want that flexibility as a deployer.

Fair enough !
I agree with you that going that path needs people and skill sets.

> I would not claim that V2 fits your description, personally. There's very little Spring exposed in that version, and that's also why it was so inflexible in a lot of areas. I think it goes hand in hand.
> 
> Most of the custom XML dialects we created were ultimately in the way, both for creating extensions and for configuring advanced use cases. Some of them we're stuck with, but I don't think it's the right direction longer term.

I understand. I agree that custom XML dialects add to the cufusion (for a non Java/XML guy)

>> For the large majority of software I came across in my career, there is
>> a clean cut between how the software is made, and how it’s configured
>> (when deployed). For the pros, there is the soft learning curve : some syntax
>> to learn about and you’re ready to go. Even if the software is written in a
>> language or a framwork you never heard of, you can make it run (and make it
>> do you want it to do)
> 
> That's also why every complex software system essentially reinvents everything itself (things like configuration, extension management). If you're using Spring, you can take that approach and hide everything, or you can do about half the work and just directly use plain Java objects wired together creatively. We're stuck with some extra work because of the legacy config files, but for a lot of the newer features, there is a ton of time saved by not doing that.

I see the point.

>> When my path made me meet Shibboleth, I was not familiar with the
>> whole Java echosystem (what the hell is a bean anyway :) I was even rather
>> hostile to all Java/XML technology (but that’s a personal opinion) I’ve
>> struggled with the fact that I have to manipulate XML files, to describe beans,
>> that interact with each other in flows. It’s powerful, you have control over
>> what the software does, but I found the learning curve steep.
> 
> As the documentation has been extended, I don't believe the vast majority of people ever need to worry about web flows unless they're trying to extend the system, and if you have to do that, that's a development activity.
> As for the XML, that's just what this system is, and XML experience is a prerequisite to configuring it, as are basic Java and Spring experience. We've never hidden that requirement.
> 
>> My purpose here is that some deployers are not developers. They
>> can easly understand the concepts (you feed it metadata, you make it
>> generate attributes in some fashion, relase them, etc)
> 
> I think you're overestimating how easy those concepts are for people. In fact, I would claim that there are as many people coming at it from the opposite end, who can handle the XML after a bit of exposure but can't grok the SAML because there simply are no books you can get to learn it.

SAML is not obvious for sure. But I don’t argue the fact that when you intend to deploy a software handling a protocol at least you have to understand that protocol. For an XML/Java novice, you have the double penality if I may say, deal with the protocol and le sotfware :)

> If I had to review the sum total of feedback over the years, I would say that the majority of it tends to focus on the need for understanding metadata than understanding XML.
> 
>> but when you try to
>> write it down, you have to deal with XML namespaces/schemas, beans,
>> references, properties. That’s hard (at least I found it hard) The
>> documentation is great (I insist really fantastic) and people on the mailing list
>> are also very helpfull (kudos to Scott \o/) but when you've never done
>> Java/XML stuff in your life, you will have a hard time. That’s what I felt and I
>> wanted to share with the community.
> 
> There is no question that anybody without a Java/XML background will have a hard time, moreso with V3 than before I would say.
> 
> I think it's worth noting that most of the complex uses of namespaces are gone or are being removed. They're already pulled from the filter schema and I think we'll pull them from the resolver next. Spring doesn't really do anything with namespaces itself, just the p: and c: shorthand ones. All the Spring syntax is one defaulted namespace.
> 
> I completely agree with you that gratuitously injecting the need for namespaces into the mix for deployers is bad, and I disagreed with it from the very beginning. Most of the places in the SP that rely on a mix of namespaces were emulating work done in the IdP that I didn't really like.
> 
> I appreciate that you found the documentation helpful, and I think your perspective on where it would be improved would be useful. I think it's too dense in places right now, but that's mostly a function of time needed to break some things apart and produce more examples.

What I really appreciated and found really helpfull was the examples and sample use cases (found in the documentation and provided by people on the mailing list)
So whenever possible it would be very nice to provide examples.

>> In the 3.x track, I’ve seen some “*.properties” files emerge with key
>> value syntax that let you configure some aspects of the software (without
>> even knowing that those are fed to beans). Is it something that will be
>> generalized for other aspects of the configuration (metadata sources,
>> attribute resolving/filtering etc) ?
> 
> Personally I don't think so. Using properties to configure anything that's fundamentally hierarchical (like the resolver) or contains a sequence of things like metadata or filter rules is brutal (and I actually don't think even possible to express in the Spring files). I don't think it's an improvement, personally. If there were one metadata source, then sure, it would be easy. But that isn't generally true.
> 
> I also observe that a ton of confusion continues to come from the mixing of properties with the XML, and since the XML isn't going anywhere, that says to me that the properties are a problem in many cases. I think they work well for configuring the "big" settings that don't change much and that don't ever need to be reloaded.

For example what I found confusing was the fact that LDAP authentication Connector properties was handled by properties files, but attribute resolving Connector (from the same LDAP) was handled directly in XML.

> But if you have something in mind, mock it up and post it. My sense is that you'll run into problems very quickly, but maybe you're seeing something I'm not.

For now nothing in mind, but if I come up with something I’ll let you know.

scott, thank’s again for taking the time to provide this answer !

Youssef