Shibboleth Developers

["Scott Cantor" <>]

Left something out...second try...

I guess I volunteered something here, I'll just do this in email until it's
more clear what we're going to do, then I can just incoporate it into the
protocol document draft later.

The issue is, I guess, whether we want to replace the old request protocol
that was used as a placeholder up until now with a more complete request
message derived from the SAMLv2 spec. The motivation (as I understood it)
was to feature-enrich the 1.3 release to put it on more equal footing with
existing Web-ISO's that people have deployed (e.g. A-Select, pubcookie, CAS,
cosign, etc.)

For me personally, the original full 2.0 timeframe of late 2005 is livable
for these features. I would favor doing this more because it's a head-start
on both the 2.0 work itself, and also forces some changes to the code design
to accommodate the multi-protocol behavior that we'll need for other
deliverables anyway.

Anyway, this is the current (and likely final) AuthnRequest schema (with the
bits from the type inheritance stuck in by value to make it easier to see
everything). It's kinda big.

<element name="AuthnRequest" type="samlp:AuthnRequestType"/>
<complexType name="AuthnRequestType">
  <sequence>
     <element ref="saml:Issuer" minOccurs="0"/>
     <element ref="ds:Signature" minOccurs="0"/>
     <element ref="samlp:Extensions" minOccurs="0"/>
     <element ref="saml:Subject" minOccurs="0"/>
     <element ref="samlp:NameIDPolicy" minOccurs="0"/>
     <element ref="saml:Conditions" minOccurs="0"/>
     <element ref="samlp:RequestedAuthnContext" minOccurs="0"/>
     <element ref="samlp:Scoping" minOccurs="0"/>
  </sequence>
  <attribute name="ID" type="ID" use="required"/>
  <attribute name="Version" type="string" use="required"/>
  <attribute name="IssueInstant" type="dateTime" use="required"/>
  <attribute name="Destination" type="anyURI" use="optional"/>
  <attribute name="Consent" type="anyURI" use="optional"/>
  <attribute name="ForceAuthn" type="boolean" use="optional"/>
  <attribute name="IsPassive" type="boolean" use="optional"/>
  <attribute name="ProtocolBinding" type="anyURI" use="optional"/>
  <attribute name="AssertionConsumerServiceIndex" type="unsignedShort"
        use="optional"/>
  <attribute name="AssertionConsumerServiceURL" type="anyURI"
        use="optional"/>
  <attribute name="AttributeConsumingServiceIndex" type="unsignedShort"
        use="optional"/>
  <attribute name="ProviderName" type="string" use="optional"/>
</complexType>

As a first cut, these are the obvious and self-evident bits:

@ID
@Version (fixed at 2.0 if we profile the 2.0 message)
@IssueInstant (replaces the Shib time parameter, somewhat)
@Destination (location of Shib SSO Service, aka HS)
<Issuer> (replaces providerId parameter)
<ds:Signature> (allows signing)

These are the bits we can support without much work:

@AssertionConsumerServiceIndex
Or
@AssertionConsumerServiceURL
@ProtocolBinding
(replaces the shire parameter with a richer metadata-aware set of
attributes)
@AttributeConsumingServiceIndex
(sort of a win here, if we have the metadata to support it, we can start
actually doing attribute push with a query by reference if we want to)
<NameIDPolicy> (just lets you specify the kind of identifier you want back,
but we probably need to discuss the AllowCreate flag and the notion of
persistent IDs for the 1.3 release)
<Subject> (sanity check when refreshing a session, you can send the original
subject element, when using something other than a handle anyway)

These are the bits we probably *want* to support if we actually do this,
based on the reasoning, but none of them are particularly simple:

@ForceAuthn (so-called session reset flag)
@IsPassive (used for silent probes for SSO)
<RequestedAuthnContext> (this is the field that can control the
quality/level/method of authn, but it's in terms of the AuthnContext concept
from Liberty/SAMLv2)

These are the bits we might support if we think it's at all useful...

<Scoping> (primarily N/A, but it does have a feature for carrying a list of
acceptable IdPs or a pointer to a list that might be interesting from a
WAYF/discovery standpoint, and it's not that hard)

These are the bits we probably blow off (i.e. profile out):

@Consent (don't ask)
@ProviderName (for richer clients, sort of)
<Conditions> (eventually useful, but not worth much with SAML 1.1)
<Extensions> (probably better to save this for 2.0, but I dunno)

The Shib target parameter becomes a max-80-byte string called RelayState
that is carried in the binding layer. No more sending real URLs, but I
wanted to dump that anyway.

Issues:

Do we address the NameIDPolicy/@AllowCreate flag?

Bindings to support? SAMLv2 specifies three primary front-channel bindings
(POST, Redirect, Artifact). We can blow off Artifact on the request side. I
was thinking only Redirect, but since POST is much easier, I'm inclined to
say let's just do both unless we thought we could get away with POST only,
but I doubt it.

Authentication...

The ForceAuthn/IsPassive/AuthnContext stuff requires digesting the request
before invoking authentication. That makes the "use a typical Web-ISO"
approach impossible unless you leave the SSO endpoint naked. Then I guess
you process the message into a short key, drop a cookie/whatever, and bounce
the browser over to the protected SAML issuing endpoint with some kind of
way to customize the redirect so as to relay the requirements in a
proprietary fashion for the authentication mechanism. I suppose thinking
about it, this is arguably better in terms of how we might eventually embed
authn modules in the software anyway, more modular.

The <RequestedAuthnContext> element is not simple. It allows for specifying
multiple context classes or context declarations by URI, and has a switch
for specifying a comparator to use (exact, maximum, minimum, better), the
trick being that all this stuff has to be configured somehow. Maybe we
profile this element down for now? It's not that hard to implement, but it's
a lot of config-level machinery, and it borders on incomprehensible, in my
layman's opinion. But hey, give the folks what they want...

Mostly, it's going to be tough to do this without plugin code. You really
need knowledge of the authentication layer to do this. Probably we need some
actual examples to work through and see if there are patterns that could be
implemented. Did I mention I'm glad to be on the SP side of this?

On the (C++) SP side, I don't see much to worry about. We have bigger fish
to fry than this. The biggest piece of work is probably handling the
Redirect binding, and I already found a DEFLATE library that should work.
Signing the query strings will be a bitch compared to Java, but it should be
doable with OpenSSL directly and using the same key we already configure in
for SSL (but we do allow for separate signing/TLS keys now).

Guess that's about it.

-- Scott