Shibboleth Developers

[Walter Hoehn <>]

Hi Ulrich,

Servlet filters are definitely a fine way to implement this.  You'll  
want to use the request wrapper functionality to override  
getRemoteUser() in order to transmit the principal name to the IdP.

As for gateway'ing your SSO attributes into the IdP's outbound  
assertions, this isn't going to be as easy.  There isn't a good way  
to do it in 1.3 without substantial customization of the IdP.  The  
principal name is the only piece of data transmitted from the ISO to  
the attribute resolution layer.  Bugzilla #514 proposes changing this  
for 2.0.

-Walter


On Sep 29, 2006, at 5:22 AM, Ulrich Bæch-Laursen wrote:

> Hi there,
>
>
>
> I am currently a part of a team trying to extend the Shibboleth IdP  
> with a container authentication mechanism. We’re building a number  
> of servlets to handle the authentication of the user and in this  
> scenario we have a few uncertainties:
>
>
>
> 1: We’re using a servlet-filter to catch the initial request for  
> auth from the SP to the IdP, the servlet filter then redirects the  
> user to our auth mechanism where he/she logs in. This produces a  
> number of attributes such as name (cn), address (postalAdress) etc.
>
> We’re just not sure about how to apply these attributes to the  
> session, so that the IdP transfers these attributes to the SP when  
> it regains focus?
>
>
>
> 1.2 Is using a servlet-filter the ‘appropriate’ way to deal with  
> authentication on the IdP or are there easier or better ways to do  
> this?
>
>
>
> 2: When using our own auth mechanism, how do we configure the SP/ 
> IdP setup so that they acknowledge the mechanism instead of the  
> BASIC auth we’re using now?
>
>
>
> Med venlig hilsen / Best regards
>
> Ulrich Bæch-Laursen
>
> Ulrich Bæch-Laursen
> Systems developer / MCSE
> Direct: +45 7230 6444
> Mobile: +45 2086 1435
> E-mail:
>
>
> TietoEnator
> Telecom & media
> Phone: +45 7230 6400
> Fax: +45 7230 6440
> Ved Lunden 12
> DK - 8230 Åbyhøj
> www.tietoenator.com