Shibboleth Developers

[Scott Cantor <>]

Nate's doing a editorial pass, I'll just supply some answers.

> 3) section 3, RH7.2,  bullet one - "The most recent Red Hat RPM 
> (1.3.27-2 as of this writing) is sufficient for use with Shibboleth. 
> You can use the older version of OpenSSL included, for this release, 
> but be advised this may change in the future."
> 
> -- I assume  that's a RH RPM for openSSL? Or is the number 
> sufficient to identify it?

No, Apache.

> 7) Application, Applications element, providerId attribute value..... 
> my current understanding is that this value will  have to be provided 
> to the Federation, for  inclusion in the metadata? If that's true, I 
> think we should mention that likelihood.....

It's likely to be chosen by the deployer and given/registered to the
federation.

> 9) Audience -- "The Audience element is used in the Policy element to 
> specify one or more SAML audience URIs to treat as valid while 
> processing assertions."
> 
> -- worth explicitly stating that these are audience values included 
> by origins, in the assertions?

I'd rather not say too much, but maybe I said too little. Arguably we can
say nothing, but we need urn:mace:inqueue in the config file for 1.1 origins
to work.

> 12) Errors - last sentence...  "The last two attributes are examples 
> of tags that can be inserted at runtime into the templates. Arbitrary 
> attributes can be used."
> 
> -- not sure what the last sentence  means.....

I made it possible to stick any attribute you want in <Errors> and if
there's a matching ShibMLP tag in the template, it will plug it in. The two
we used to have are just examples of that (I added styleSheet as a third).

> 14) Path  -- requireSession -- "If false (the default), applications 
> are responsible for ensuring that a session exists if necessary, 
> so-called lazy session establishment."
> 
> -- ummmm... do we really want the default here to be  FALSE?

Yes, just like Apache doesn't do anything just because you define some
settings in <Location> or <Directory>. It's the settings that do the work,
not the container element. requireSession="false" just means nothing. It
doesn't even explicitly mean "lazy sessions", it just means if you want a
session, that's the only way you're gonna get one. I guess we could say
something along those lines.

> -- there's no description of the uri attribute.....

The uri attributes always mean that you can put the content of the element
in a file and point to it.

> 16) RelyingParty
> 
> -- "name: Identifies the origin site or group of sites to which the 
> credentials specified in the element apply."
> 
> I suppose I'm supposed to know this by this point...... but I 
> don't.... where does the target obtain the value that it compares 
> against the name value of this  element?

It's in the Xpath
//Assertion/AuthenticationStatement/Subject/NameIdentifier/@NameQualifier or
any SiteGroup/@Name which that value is contained in according to metadata.

In 1.2, we also put that same value in //Assertion/@Issuer which makes
things a little cleaner.

But I don't think that helps...umm, lessee. When you authenticate, the
assertion identifies the identity provider (origin site). We chose a
particular spot for that information (SAML says nothing about it). We map
that value to a set of "groups" based on metadata. The set of group names
plus the original providerId are the strings that are matched.

> 17) Sessions -- "If default ports are used (and thus left 
> unspecified), browsers will generally return cookies set via SSL to a 
> non-SSL server."
> 
> -- should the last word be port, not server?

Guess so. Virtual server might be better.

> -- "cookieName: Optionally specifies the name given to in-memory 
> session cookies that are associated with this application. If 
> ommitted, Shibboleth will generate a cookie name for you of the form"
> 
> -- too many mmmm's in omitted

It's a cookie, they're mmm delicious.

> 20) Section 4b
> 
> <shibmlp tag-name /> -- does case matter?

Probably not.

> 21) section 4.c - last paragraph -- does calist still exist?  
> replaced?

Gone, replaced with TrustProvider information, either global, or per
application, and then per origin or site group.

-- Scott