Shibboleth Developers

[Chad La Joie <>]

It's not directly stated that there must be one-to-one relationship 
between requests and threads but it's strongly implied (for example, the 
spec says that the request and response objects have to be scoped to one 
thread for the duration of the request).  I'm sure some one could come 
up with an inventive way to get around this but I've never seen any 
container try it.  The thread local method has worked in all the 
containers I've used (Tomcat, JBoss, Webspehere, Weblogic, Resin, Jetty)

Walter Hoehn wrote:
> Agreed, although this is relying on unspecified behavior.  I can't 
> imagine why any container would use a different thread for the filter 
> and the servlet, though.
>
> -Walter
>
>
> On Oct 3, 2006, at 5:22 AM, Chad La Joie wrote:
>
> > Hey Ulrich,
> > Probably the most straight-forward way would be the bind the 
> > attributes to thread-local variables within the filter then write a 
> > custom data connector, for the attribute resolver, to pull the 
> > information from the thread.  That way you won't have to customize the 
> > IdP code, you can just use the normal IdP extension mechanism.
> >
> > Here's a link to information about writing a custom connector:
> > https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/CustomDataConnector 
> >
> >
> > Ulrich Bæch-Laursen wrote:
> > > 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
> >
> > --Chad La Joie             2052-C Harris Bldg
> > OIS-Middleware           202.687.0124

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124