Skip to Content.
Sympa Menu

shibboleth-dev - Re: Shib 1.3 configuration

Subject: Shibboleth Developers

List archive

Re: Shib 1.3 configuration


Chronological Thread 
  • From: Tom Scavo <>
  • To: Steven Carmody <>
  • Cc: Scott Cantor <>, Shibboleth Development <>
  • Subject: Re: Shib 1.3 configuration
  • Date: Wed, 25 May 2005 08:58:31 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nAWmpjlk4njKU5OcdgFQh2qBjez9O65ZhtQ32ouoGEPGk1dpoQmvCGliSj1s2mKzm32+Tedh17dF+9cFhgvx9+4iku62dtp7Ak01imsA/+Hx6xZ2Uqqoj9mBwkGLTCmVwx1u9gWkDMOjbTc3pO7U3e3F+TLGlXlRFojXOeSp/M8=

On 5/24/05, Steven Carmody
<>
wrote:
> Scott Cantor wrote:
> > Steven Carmody wrote:
> >
> >> I would like to open the question, tho, of having the distro's include
> >> keys and certs for the two dummy entities...
> >
> > We already do. It only helps marginally, since you have to tell Apache
> > about it, but I believe it's helpful in general.
>
> but,if/when we can get apache out of the way....it should help a lot (-:

Yes, I've been working with an all-Java deployment since early April
(no apache). With Howard's help, I have a SSL-enabled Tomcat hosting
both the IdP and SP. His straightforward installation steps led me to
the point where I was able to

- modify the IdP and SP configs (to separate the entities)
- modify the IdP and SP metadata (to separate the metadata)
- create separate self-signed SSL certs for both the IdP and SP (using
keytool)

Once I get Shib 1.3 up and running with the Java SP, I plan on adding
a separate browser-facing SSL credential to the IdP (and use this for
signing).

As far as I can tell, in a typical Shib deployment the following
credentials are (ultimately) needed:

1. the IdP needs a signing credential (for authn assertions)
2. the IdP needs a browser-facing SSL credential (for SSO service)
3. the IdP needs one or more SP-facing SSL credentials (for AA,
artifact resolution, etc.)
4. the SP needs a browser-facing SSL credential (for assertion consumer
service)
5. the SP needs an IdP-facing SSL credential (for mutual authentication)

Out of the box, it would be a mistake (I think) for both the IdP and
the SP to share a single SSL credential. This makes it difficult to
generalize the config (same arguments as the providerIds). Each
entity should have a separate SSL credential.

Then there could be a series of "how tos" that explain

- how to separate the IdP SSL credential into independent
browser-facing and SP-facing SSL credentials
- how to separate the SP SSL credential into independent
browser-facing and IdP-facing SSL credentials
- how to upgrade the IdP browser-facing SSL credential to a commercial
cert and how to reconfigure the IdP to use this cert for signing
- how to add and secure an AA endpoint
- how to add and secure an artifact resolution endpoint

and so forth.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page