Shibboleth Developers

["Howard Gilbert" <>]

> I'm obviously not on a campus IT staff, so I need to ask; is there a
> reason it is inherently preferable to test these technologies with an
> internally hosted test site versus a remote one, beyond the ability to
> fiddle around with it more directly if you want to fully understand the
> capabilities on both sides?  Doesn't this seem to move away from a
> simpler installation to a more complex one?

There are two reasons. First, this is an infrastructure product so once you
put it in production it better not fail. However, stuff happens, and when
you are simulating stuff happening it is better if you are destroying a lab
network than the campus network.

The other point is that this is a security product, which means that as soon
as it becomes active it is a potential point of attack with regard to any
data it controls.

Also, some forms of testing require that even if you are only building an SP
that you have access to an evil IdP, especially something small that you can
configure to do strange things. 

> The question I'm left with is what constitutes "controlled".  The
> self-contained IdP and SP combined deployment seems to require a site
> to understand more about the SP, IdP, and Shibboleth before putting
> either in production than deploying either individually against a test
> service or prospective partner.  This might be good or bad.

If you are an SP you need to understand IdP Metadata to be able to talk to
the IdP or diagnose problems. So someone bringing up an IdP needs knowledge
to create an idp.xml, create an IdP Metadata, and have a passing knowledge
of SP Metadata, while an SP site needs to create sp.xml, SP Metadata, and
have a reading knowledge of IdP Metadata.

However, you are absolutely right with regard to some of the nuanced
elements of real deployment. Someone who is really interested in the SP
doesn't need to know anything about how to hook a real IdP up to CAS,
Kerberos, or LDAP. He can do quite nicely with Tomcat authentication and
attributes read from an XML file.

Similarly, someone who is deploying an IdP doesn't need anything more as a
protected resource than /secure/test.jsp.

So all the complex options that make the protocol really useful can be
ignored on one side or the other, but it is still nice to have the absolute
minimum basic bare easy to read minimum configuration of the other end to
test against.

> It's completely possible to do a completely internal deployment today,
> and it's also possible to test against the remote service.  It's good
> to have both capabilities.  

This brings up a point I had missed. If you add Shibboleth to a large
existing system it may have a legacy authentication mechanism that it still
supports. However, if you are bringing up a bucket of data and you want to
put one filter in front of it to control access, then if you bring up an
SP-only environment you are really claiming that you have no local customers
for the data. 

I don't question Scott's claim that I am in the minority. However, I am not
alone in that minority. I only jumped into this thread after Tom said a lot
of things I agreed with, and I didn't want him to feel lonely. While I do
not claim my position is "right", I reject any claim that it is "wrong".
Just recognize it as a possible requirement for some deployments.