Skip to Content.
Sympa Menu

shibboleth-dev - Central WAYF + Distributed WAYF - Disadvantages = Embedded WAYF

Subject: Shibboleth Developers

List archive

Central WAYF + Distributed WAYF - Disadvantages = Embedded WAYF


Chronological Thread 
  • From: Lukas Haemmerle <>
  • To:
  • Subject: Central WAYF + Distributed WAYF - Disadvantages = Embedded WAYF
  • Date: Fri, 19 Sep 2008 15:14:05 +0200
  • Organization: SWITCH - Serving Swiss Universities

Recently I have had an idea how the discovery problem maybe could be
lowered. I know that no existing and widely used solution nowadays is
perfect and that the whole problem is indeed not easy to solve. However,
let me just outline you the main idea of this (hopefully) new approach:

As the subject suggests the idea is to use the central and the
distributed model in a combination that tries to preserve their
advantages and get rid of their disadvantages. If you want to know what
these are and if you need more information about what is explained
below, please just read this:
http://kelimutu.switch.ch/Embedded-DS.txt


For the quick starters:
Have you ever wondered how the GoogleAds are displayed in the web pages?
If not, have a look at a web page's source code. You will see that it
all is done via javascript. There basically are 2 scripts to do the job.
One script is the same for every web page that displays google ads. It
is loaded from a remote server operated by Google and it is the same
script for all web pages world wide. The other script contains some
preferences and an ID. It is located locally in the HTML code of the web
page.
The interesting thing is that all the ads shown on the web pages are
rendered by these two scripts. The other interesting thing is that
cookies are transmitted as well for requests to load Javascripts from
remote servers.

Taking these ideas together and taking into account that this apparently
seems to be working very well for Google, I have created a proof of
concept for an embedded WAYF/Discovery Service that works the almost the
same way and maybe accomplishes the goals of combining only the
advantages of the central and distributed approach. This embedded
approach makes use of the fact that the cookies are transmitted when the
Javascript is loaded from the remote host. The remote host then can
dynamically generate the Javascript that is returned based on the
Cookies, e.g. make sure the right IdP is preselected by using the
_saml_idp cookie.

If you want to have a look on how this works:

1. Go to https://kelimutu.switch.ch
2. Just first have a look at the source code to see what I talked about
3. Go to https://aai-demo.switch.ch/secure (this will send you to our
AAI Test federation central DS that will display all entries)
4. Choose the top entry ("AAI Demo Home Organization")
5. Now you should be on a page that just displays the attributes
6. Go back to https://kelimutu.switch.ch (the entry you chose should be
selected)

You also could play around with the setting "Remember selection for this
web browser session" repeating the above steps.

What I would be interested in is to hear:
a. What you think about this approach?
b. Would you as an SP administrator use such an embedded WAYF?
c. If not, why not?

If this approach is considered as useful as I think it could be, I will
include its source code in our PHP WAYF/Discovery Service as well.

Lukas

--
SWITCH
Serving Swiss Universities
--------------------------
Lukas Haemmerle, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
,
http://www.switch.ch



Archive powered by MHonArc 2.6.16.

Top of Page