Shibboleth Developers

[Stefan Krist <>]

Hi guys,

I've got a question about implementing an additional feature to an
IdP-2.0.

Here is a little picture that might help to understand what I'm trying
to do http://webuser.hs-furtwangen.de/~skrist/CONCEPT_MODIFY_IDP.png

Step 1+2 is supposed to be a normal shibboleth authentification. When
the user accesses the web site, a script starts to pull values out of
the so called "delegation database" and shows it in combo boxes on the
web site (Step 3).

In this database is a little schema with a few tables, where users can
store information about what attributes they want to delegate to other
users in the federation.

The user_a, who authenticated himself to the delegation web site, can
now select out of a list of users who delegated certain attributes for
certain services to him. Let's say user_b has delegated a simple
attribute to user_a for the use with service_a. The user_a selects this
setup in the delegation web site and clicks on "use selected
delegation".

The delegation web site makes sure, that all cookies in question are
deleted, so that the user approaches the IdP-D without a security
context.

Step 4 is then, that this web site sends a simple request with the
selected information to the IdP-D - with any protocol - a propreitary
request. The IdP-D will then use this Information to issue an
Authentication Assertion for user_b, without the actual authentication
of user_b. This was done when user_b inserted the delegation entries in
the database. Since IdP-D knows only the delegated attributes from the
delegation database, no other attributes can be sent to the SP (Step 5).

Therefore, IdP-D is an IdP that authenticates a user without an actual
user/password combination - it simply creates the assertion if the
values are really in the database and only if the request comes from
that web site via the propreitary "channel".

The SP should (please correct me if I'm wrong here) establish a new
security context for user_b with a subset of attributes and the service
should not be able to recognize anything about this previous
"delegation".

The modification I want to implement in the IdP-D should be as modular
as possible. So that it could simply be attached to a normal IdP,
preferably without modifying the code, maybe by implementing a bean and
adding it to the $IdP/conf/internal.xml.  What would be the best way of
implementing this in a modular manner, so that the next release of an
IdP doesn't have to be patched in order to do this "delegation"?

Please excuse this long email!
Many thanks in advane!

Best regards,
Stefan

--