Shibboleth Developers

[Tom Scavo <>]

On Sun, 31 Oct 2004 00:28:33 +0100 (BST), Alistair Young
<>
 wrote:
> There was mention of having to delete the cookie if the user wanted to
> authenticate at a new IdP. We have many users who would want to do just
> this, users who are studying at more than one institution and may have
> different SP access privileges according to their current institution.
> For a lot of users, deleting a cookie may be beyond them :)

Not only that, but deleting the common domain cookie also deletes the
user's authn history.  Remember, the value of the common domain cookie
is a *list* of all IdPs that the user has authenticated against (most
recent IdP last).  Deleting the cookie is like throwing out the baby
with the bath water (so to speak :).

> It would be nice if the user could bring their IdP domain with them when
> starting a SAML session with an SP.
> You've probably heard a bit about the Guanxi domain suffix attempt to make
> the process of IdP discovery a bit more friendly for the user.

Yes, that's a good idea, but now the user is responsible for sending
along another piece of data to the SP.  What if the user does not send
the data that the SP requires?  What method of IdP discovery does the
SP fall back on (if any)?

> This is in no way to say that the domain cookie/WAYF methods are
> "unfriendly" but in a large federation the WAYF lists could get very
> large.

Yes, but I could imagine how a WAYF might use a cookie to initialize
that (long) list with the user's previously used IdP.  The common
domain cookie takes that one step further and eliminates the
interactive part altogether, but in the process the user loses the
capability to choose a new IdP somewhere down the road.

> I sometimes get mixed up between SAML and Shibboleth, as the SAML profiles
> are all post-authentication (I think!) and the Shibb ones are SP first,
> with authentication coming second, after IdP discovery.

SAML1 starts at the IdP but SAML2 is SP-first.  Therein lies the
introduction problem.

> The domain cookie is then ideal in such post-authentication scenarios.

No, the common domain cookie attempts to solve IdP discovery in SAML2.
 (If you want to read about the details of the common domain idea, go
to sun.com and search for "common domain cookie".  A detailed
implementation of the SAML 2.0 Web Browser SSO Profile with Identity
Provider Discovery is attached.  Hope this helps.)

> We're still investigating the consequences of allowing a user to divulge
> their 
> 
>  to an SP and initially only in the context of the
> Bodington VLE and allowing that VLE to then talk directly to a Guanxi IdP
> to have them authenticated. Their password is only ever entered at their
> IdP.
> It all relies on trust, which is what the federations are founded upon.
> Can trust be counted on, to allow a user to divulge their ID to a trusted 
> SP?

The privacy issue must be considered here.  The whole point of
federated identity solutions such as Shib and SAML is that the user
need not identify him/herself at the SP.  By requiring an e-mail
address, you've just blown the privacy issue wide open again.

> many irons in the fire at the moment but your comments are much appreciated.

I hear ya! :-)

> thanks again,
> 
> Alistair

Cheers,
Tom

> 
> > On Sat, 30 Oct 2004 23:51:00 +0100 (BST), Alistair Young
> > <>
> >  wrote:
> >> Would it be possible to see the conformance doc? As part of our JISC
> >> middleware project, Guanxi, we're investigating an IPDP that doesn't
> >> require centralised resources for a federation. It also addresses the
> >> concerns raised of multiple IdP for a user and how they change it.
> >
> > Alistair, would you care to describe your solution?
> >
> >> It's also unclear how the domain cookie can be updated reliably if there
> >> are hundreds or thousands of users authenticating and each IdP trying to
> >> update the cookie at the same time.
> >
> > This doesn't seem to be a problem.  After the user authenticates, the
> > client is redirected to the common domain where after the cookie is
> > updated on the client.  If you're worried about load on the common
> > domain server, that shouldn't be a problem since authn is an
> > exceptional event in an SSO system.
> >
> >> Of course, there's also the issue of users disabling cookies, although
> >> institutions could insist that cookies be enabled to use the system but
> >> how ethical is this?
> >
> > This isn't much of a problem either.  Like JavaScript, you can disable
> > cookies on the browser, but if you do you sacrifice a lot.  In
> > practice, cookies are not disabled (and requiring this is not as
> > grandiose as it sounds).
> >
> >> We're keen to allow simple SAML models to be used, where, for instance,
> >> a
> >> couple of VLEs can be hooked up via Shibboleth or Guanxi, without the
> >> need
> >> for extra resources such as a central domain server.
> >
> > A common domain server need not be a separate physical host.  I think
> > the intention is that it's more of a DNS trick than anything else.
> >
> > Cheers,
> > Tom
> >
> >> > Thanks for reviewing...my comments below.
> >> >
> >> >> - Applicable Shibboleth version is not mentioned anywhere in this
> >> >> document (intentionally, I presume, but it's still a significant
> >> >> omission)
> >> >
> >> > Intentional. There's an unpublished conformance doc, and there are no
> >> > implementations of Shibboleth that are conformant. This is not about
> >> > implementation, so why should we mention one?
> >> >
> >> >> - In Example 3.1.1.3, remove the URL encoding for clarity
> >> >
> >> > Why? Then the example would be wrong...
> >> >
> >> >> - In Examples 3.1.2.1, 3.2.1.1, and 3.2.2.1, insert indentation for
> >> >> clarity.  Also, refrain from using default and/or redundant
> >> >> namespaces.
> >> >
> >> > Will indent. I disagree about the namespaces, and I don't think any of
> >> > them
> >> > are redundant, but I'll check. I use default namespaces all the time.
> >> They
> >> > save space.
> >> >
> >> >> - Not sure sections 3.3 through 3.7 should be called "profiles"
> >> >> - Combine sections 3.3 through 3.5
> >> >
> >> > I'm reworking 3.3-3.5 back into the earlier sections (I agree), but
> >> they
> >> > are
> >> > all SAML profiles, IMHO. Except maybe 3.6, which just points at one.
> >> 3.7
> >> > is
> >> > probably going to be the basis of an actual submitted SAML profile.
> >> >
> >> >> - IMHO, section 3.6 should be omitted.  As written, it adds nothing
> >> to
> >> >> the existing SAML2 "profile", which itself is vague at best.
> >> >
> >> > I think we, umm, disagree about the vagueness, or at least the
> >> necessity
> >> > for
> >> > it to be any less vague. "Doesn't solve an unsolvable problem" I would
> >> > agree
> >> > with.
> >> >
> >> > We have to reference it because this is a SAML 1.1 based set of
> >> profiles,
> >> > and that's a SAML 2.0 profile that wouldn't otherwise apply.
> >> >
> >> >> Moreover, there seems to be a lot of overlap between the IdP
> >> Discovery
> >> >> Profile and the WAYF.  Perhaps the two should be combined?
> >> >
> >> > I do, section 2.3 already allows for the use of that profile. The WAYF
> >> is
> >> > a
> >> > non-normative component, it wouldn't be appropriate to require one to
> >> > utilize the SAML profile. It dovetails with it fine, since it's
> >> > essentially
> >> > usable as a shared domain. It effectively just offloads the SP's role
> >> of
> >> > participating in the profile to it.
> >> >
> >> > -- Scott
> >> >
> >> >
> >>
> >>
> >
> 
>
SAML 2.0 Web Browser SSO Profile with Identity Provider Discovery

Here is a possible implementation of the SAML 2.0 Web Browser SSO Profile 
combined with the Identity Provider Discovery Profile where both the service 
provider (SP) and the identity provider (IdP) use the HTTP Artifact binding.

The implementation assumes that a local authentication service 
(authentication context class PasswordProtectedTransport) exists at the IdP 
and that the auth service accepts a target parameter.  After authenticating 
the principal, the auth service redirects the client to the URI value of the 
target parameter.

The implementation also assumes the existence of a common domain.  After a 
principal is authenticated by the IdP, the client is redirected to the common 
domain cookie writing service.  Likewise, after a client requests a secured 
resource, the SP redirects the client to the common domain cookie reading 
service with the intent of learning the principal's preferred identity 
provider.

The message flow begins with a request for a secured resource at the SP.

1) [Normative] The client requests a target resource at the SP:

  https://sp.com/myresource

The SP performs a security check on behalf of the target resource.  If a 
valid security context at the SP already exists, skip steps 2--23.  If the SP 
knows the preferred IdP of the client (because there is only one IdP or the 
URI of the IdP is included as a parameter in the request), skip steps 2--5.

2) The SP redirects the client to the common domain cookie reading service.  
The URI of the SP (with RelayState parameter attached) is appended to the 
redirect URL.

3) The client requests the common domain cookie reading service:

  https://sp.cd.com/read?target=target

  where target = https://sp.com/SAML2/SSO?RelayState=token

If the common domain cookie exists, it is automatically sent with the request 
at step 3.

4) The common domain server attempts to read the common domain cookie in the 
request and redirects the client back to the SP.  If it exists, the value of 
the common domain cookie is appended to the redirect URL.

5) The client accesses the SP again:

  https://sp.com/SAML2/SSO?RelayState=token&_saml_idp=URIlist

  where URIlist is specified by the Identity Provider Discovery Profile.

The SP parses the query string and determines the client's preferred IdP at 
step 6.

6) [Normative] The SP redirects the client to the single sign-on (SSO) 
service at the IdP.  The RelayState parameter and a SAMLart parameter are 
appended to the redirect URL.

7) [Normative] The client requests the SSO service at the IdP:

  https://idp.com/SAML2/SSO/Artifact?RelayState=token&SAMLart=artifact

If the SP does not use an HTTP Artifact binding at step 6, skip steps 8 and 9.

8) [Normative] The SSO service dereferences the artifact by sending a SAML 
ArtifactResolve message to the artifact resolution service at the SP:

  <samlp:ArtifactResolve
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="..."
    Version="..."
    IssueInstant="...">
    <saml:Issuer>...</saml:Issuer>
    <ds:Signature>...</ds:Signature>
    <samlp:Artifact>artifact</samlp:Artifact>
  </samlp:ArtifactResolve>

9) [Normative] The artifact resolution service at the SP returns a SAML 
ArtifactResponse message (containing an AuthnRequest element) to the SSO 
service at the IdP:

  <samlp:ArtifactResponse
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="..."
    InResponseTo="..."
    Version="..."
    IssueInstant="...">
    <saml:Issuer>...</saml:Issuer>
    <ds:Signature>...</ds:Signature>
    <samlp:AuthnRequest>...</samlp:AuthnRequest>
    <samlp:Status>
      <samlp:StatusCode Value="..."/>
    </samlp:Status>
  </samlp:ArtifactResponse>

The SSO service processes the AuthnRequest and performs a security check.  If 
the user already has a valid security context or is otherwise directed by the 
AuthnRequest to forgo authentication, skip steps 10--17.

10) The SSO service redirects the client to the local authentication service. 
 The URI of the common domain cookie writing service is appended to the 
redirect URL.

11) The client requests the authentication service at the IdP:

  https://idp.com/auth/controller?action=login&target=target

  where target = https://idp.cd.com/write?target=target

  where target = https://idp.com/SAML2/SSO?RelayState=token

12) The authentication service challenges the user for credentials.

13) The user supplies the required credentials to the authentication service.

14) The authentication service verifies the user's credentials, creates a 
security context at the IdP and redirects the client to the common domain 
cookie writing service.

15) The client requests the common domain cookie writing service:

  https://idp.cd.com/write?target=target

  where target = https://idp.com/SAML2/SSO?RelayState=token

If the common domain cookie exists, it is automatically sent with the request 
at step 15.

16) The common domain server checks for the existence of the common domain 
cookie.  If it exists, the URI of the IdP is appended to the cookie value, 
otherwise the cookie takes on the value of the URI.  In either case, the 
common domain server sets the cookie on the client and redirects the client 
back to the IdP.

17) The client requests the SSO service again:

  https://idp.com/SAML2/SSO?RelayState=token

18) [Normative] The SSO service at the IdP redirects the client to the 
assertion consumer service at the SP.  The previous RelayState parameter and 
a new SAMLart parameter are appended to the redirect URL.

19) [Normative] The client requests the assertion consumer service at the SP:

  https://sp.com/SAML2/SSO/Artifact?RelayState=token&SAMLart=artifact

If the SSO service at the IdP does not use an HTTP Artifact binding at step 
18, skip steps 20 and 21.

20) [Normative] The assertion consumer service dereferences the artifact by 
sending a SAML ArtifactResolve message to the artifact resolution service at 
the IdP:

  <samlp:ArtifactResolve
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="..."
    Version="..."
    IssueInstant="...">
    <saml:Issuer>...</saml:Issuer>
    <ds:Signature>...</ds:Signature>
    <samlp:Artifact>artifact</samlp:Artifact>
  </samlp:ArtifactResolve>

21) [Normative] The artifact resolution service at the IdP returns a SAML 
ArtifactResponse message (containing an AuthnResponse element) to the 
assertion consumer service at the SP:

  <samlp:ArtifactResponse
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="..."
    InResponseTo="..."
    Version="..."
    IssueInstant="...">
    <saml:Issuer>...</saml:Issuer>
    <ds:Signature>...</ds:Signature>
    <samlp:AuthnResponse>...</samlp:AuthnResponse>
    <samlp:Status>
      <samlp:StatusCode Value="..."/>
    </samlp:Status>
  </samlp:ArtifactResponse>

22) [Normative] The assertion consumer service processes the AuthnResponse, 
creates a security context at the SP and redirects the client to the target 
resource.

23) [Normative] The client requests the target resource at the SP (again):

  https://sp.com/myresource

24) [Normative] Since a security context exists, the SP returns the resource 
to the client.

Issues:
- What should the common domain reading service do if the common domain 
cookie does not exist?
- What should the SP do if the common domain reading service does not return 
the common domain cookie value?