Shibboleth Developers

[Ulrich Bæch-Laursen <>]

Hi Walter,

Thanks for the quick response. Our aim is to customize the IdP to gateway
all the SSO attributes into the outbound assertion due to our somewhat
simplified setup using a bilateral deployment.

Right now we're developing our own auth mechanisms via the previously
mentioned servlet filter. So the customization will be our next task.

What are your suggestions on how to do this? If you could supply us with a
list of areas (conf, source code etc.) where the IdP needs to be customized
in order to wrap all the attributes, that would be a great help.

Have others done this before? If so we could gain knowledge by example by
examining their customization.

If we succeed we would definitely contribute the source code to the
community if you would like that.


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

-----Oprindelig meddelelse-----
Fra: Walter Hoehn 
[mailto:]
 
Sendt: 29. september 2006 16:54
Til: 

Emne: Re: IdP Extension

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
>
>
>
>