Skip to Content.
Sympa Menu

mace-opensaml-users - RE: Building a SSO prototype using openSAML

Subject: OpenSAML user discussion

List archive

RE: Building a SSO prototype using openSAML


Chronological Thread 
  • From: Scott Cantor <>
  • To: ,
  • Subject: RE: Building a SSO prototype using openSAML
  • Date: Fri, 19 Mar 2004 01:44:33 -0500
  • Organization: The Ohio State University

> I have to create a web application protoype which supports
> SSO, so i am interrested in openSAML. I have read that there
> is no real tutorial about how to use the openSAML Java API
> and the Shibboleth project seems to me a little bit ... "obscure".

It's obscure in presentation, but it's a SSO system, believe me. It just
focuses on different aspects of the problem, and leaves other bits out at
the moment.

> *** Here is what i already have : ***
> - The user U1 gives his login/password into a form, on a
> login.htm page located on web server W1.

This is already not SSO. You've given your credential to W1, the resource
host. SSO is usually where you only give your long term secret to A, and it
gives W1-n a short lived token that authenticates you. The trick is to
realize that you never give your long term secret to W1-n.

> - If the login/pass is valid then the login.jsp create a
> session on W1 and then if U1 comes back to W1 he doesn't need
> to sign in again.

That's just a cookie. That's, I suppose, a sort of SSO, but that's not what
people generally mean by it. This is just using a cookie to do form based
login.

> *** What i need : *******************
> - If U1 try to leave W1 and connect to W2, the SSO idea is
> that he also would not need to enter his login/pass again.

Right. Now generalize that to the case where you do the same thing to begin
with, and you get into W1 via this same indirect mechanism. That's web SSO.

> I have no idea about how to use the openSAML API in order to
> reach this goal.

OpenSAML is just the raw message bits, it's not the running structure around
it. You need to read up on the SAML web browser profiles, which are on the
SAML web site in the bindings/profiles document. They describe two protocols
for using SAML to log into server W1 after authenticating to server A.
Shibboleth uses one of those, the POST profile. Many SAML vendors use the
other, called artifact.

> *** Some question : *****************
> - When the authentication server A1 says that user U1 is
> valid he should create an assertion about this fact and send
> it to the web server W1 ?

Basically, yes, but he does this after directly interacting with the user's
browser, not by receiving the password from W1.

> - When the user U1 leaves the web server W1 and go to W2, W1
> should send the assertion to W2 which then should ask to A1
> if the assertion is valid ?

No, each W server receives its own unique assertion from A.

> - Is the edu.internet2.middleware.shibboleth.hs.HandleServlet
> exactly what i may be looking for ?

Pretty much, yes. It's a servlet that generates signed messages that conform
to the POST profile. It doesn't do the authentication for you, but if you
secure the servlet behind your login form, then you're a long way down the
road.

The Shib target code runs in Apache or IIS and does the W half of the dance,
and processes the incoming sessions and also does attribute fetches, which
are optional.

The upcoming Shib release is a bit more able to function as a generic SAML
system, and is less privacy-centric about using handles and doing attribute
queries. We're getting there slowly.

> I'm a french student, sorry for the way i write, i hope you
> will understand my message. I hope somebody here could help
> me, thanks :-)

You write fine.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page