Shibboleth Developers

["Howard Gilbert" <>]

> > This is my original design, but Scott believes in a "one SP per
> > application" view for real security. You can deploy my code either way.
> 
> It's not a question of security, but transparency. 

I misspoke myself and misquoted you. I should have said that you believe
that the only way to characterize an Application with any real unique
features like the Attributes you will release to it is to give it an Entity
in the Metadata, which implies giving it an SP. That's just the way the
protocol administration works.

Following up on the previous discussion, there is a tension in the cookie
thing. You want the cookie scoped widely enough to cover the SP and all its
RMs, but things get confusing if it is scoped widely enough to cover two SPs
at the same network. If that is possible, then the Entity name has to become
part of the Cookie variable name, or the two SPs are going to be stepping on
each other overwriting each other's cookies.

> - making it secure across machines isn't trivial, you still have to
> implement something there (shared key, whatever) and you have to
> document what that is because it's a new protocol, provide more security
> configuration, etc.

Fifteen years ago you could have said this and everyone would nod. Even then
we knew that OSI Level 5 and 4 issues like secure and reliable transport
should be low level services transparent to the application. However, big
architectures (OSI, DCE, CORBA, even J2EE) didn't catch on. Java has some
support, but not that interoperates with some C++ standard. It isn't trivial
to do, which is why there are software stacks to do it. The problem is that
there isn't one stack everyone naturally knows to use.

I am a little better off. "Java remoting" is a growth industry. So I don't
actually have to solve the problem. I need an interface. I need some sample
code. Then if the customer wants to do it differently, they can run the
interface through some other remoting framework and be up and running in a
few hours. A lot of people have their own RM built into the application, and
I suspect they have their own preferences for doing that sort of thing.

If you tell someone, "We do it this way," they will ask, "Why not that way?"
So I say, "Here is a sample that does it this way but if you have some other
ideas, knock yourself out." That way there is no argument, and 99% of the
time they really don't want to write the code, they just want to argue about
how you did it.

> - doing it right requires the transparency that's missing in an opaque
> gateway, or the SP becomes such a large aggregation that
> ARPs/etc. becomes muddled, which isn't hard but is additional work.
> 

I am also not particularly interested in replacing SAML. From my point of
view the SP is simply an Endpoint and to some extent a proxy relay to the
RM. The Session object has two SAML replies, an Authentication and an
Attribute Assertion. There are two simple requests: give me all the
Attributes as a collection, and give me the SAML statements. Any policy is
already applied at the SP. 

The SP to RM is just a handoff of Serializable objects across a memory
boundary. If the RM wants to get Statements, it needs OpenSAML in its
classpath to deserialize them. If you can sweep transport issues under the
protocol stack, then the handoff of objects across a context (or CLI
"appdomain") boundary isn't any different from the same handoff across
machines. That is a fundamental idea of .NET, and if the answer for other
architectures is that we have to write a stack, build a PKI, and document
the whole thing from scratch, then it is time for some deep soul searching.

Which, I guess is the long winded way of saying that I don't have an
airtight solution to propose and am pissed that I am expected to come up
with one. It is easier to wave your hands and come up with four than it is
to sit down and come up with one.