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

[Youssef GHORBAL]

Hello,

	For the last 3 years I’ve been managing coule instances of Shibboleth IdP (2.x and now 3.x)
	I’m a sysadmin who have done briefly some software developpement, but I don’t define myself as a developper.
	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.
	
	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) Now for the cons side, sometimes you feel frustrated by the lack of experssivity of the configuration (or the lack of fine grained control over the software internals)

	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.

	My purpose here is that some deployers are not developpers. They can easly understand the concepts (you feed it metadata, you make it generate attributes in some fashion, relase them, etc) 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.

	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) ?

	Thank you again for the quality software and keep on the good work !

Youssef Ghorbal
Institut Pasteur