Shibboleth Developers

[Walter Hoehn <>]

Hi Ulrich,

Sorry, but you won't be able to pass the attribute through this way.   
The IdP pulls a String from the servlet request and constructs a  
local principal internally.  Your custom principal object will just  
be ignored.

-Walter


On Oct 4, 2006, at 7:15 AM, Ulrich Bæch-Laursen wrote:

> Hi again,
>
> Well we tried it the hard way and it didn't work:
> Here's what we get from our efforts:
>
> - <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/ 
> envelope/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> - <soap:Body>
> - <Response xmlns="urn:oasis:names:tc:SAML:1.0:protocol"
> xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
> xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
> IssueInstant="2006-10-04T12:02:11.364Z" MajorVersion="1"  
> MinorVersion="1"
> ResponseID="_a17ac8415c5f70ea8702591b8efce731">
> - <Status>
>   <StatusCode Value="samlp:Responder" />
>   <StatusMessage>Invalid request data.</StatusMessage>
>   </Status>
>   </Response>
>   </soap:Body>
>   </soap:Envelope>
>
> In our servletfilter that filters on the /IdP servlet we try the  
> following:
>
> chain.doFilter(new SLSTrustWrapper(httpRequest, new SLSPrincipal 
> ("testname",
> "testaddress", "testid")), response);
>
> much like the example in the ClientCertTrustFilter class.
>
> The SLSPrincipal is like the localPrincipal class but has 3 attributes
> The SLSTrustWrapper is like the ClientCertTrustWrapper class but  
> returns the
> hardcoded authtype "SLS_AUTH".
> The resolve method on class SLSConnector looks like this:
>
> public Attributes resolve(Principal principal, String requester,  
> String
> responder, Dependencies depends) {
>
>                 log.debug("Resolving connector: (" + getId() + ")");
>                 log.debug(getId() + " resolving for principal: (" +
> principal.getName() + ")");
>
>                 BasicAttributes attributes = new BasicAttributes();
>                 attributes.put(new BasicAttribute("cn",
> ((SLSPrincipal)principal).getCn()));
>                 attributes.put(new BasicAttribute("postalAddress",
> ((SLSPrincipal)principal).getPostalAddress()));
>                 attributes.put(new BasicAttribute("eduPersonTargetedID",
> ((SLSPrincipal)principal).getEduPersonTargetedID()));
>                 return attributes;
>         }
>
> And the resolver.xml file looks like this:
>
> <AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema- 
> instance"
> xmlns="urn:mace:shibboleth:resolver:1.0"
> xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0
> shibboleth-resolver-1.0.xsd">
>
>     <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">
>         <DataConnectorDependency requires="echo"/>
>     </SimpleAttributeDefinition>
>
>     <SimpleAttributeDefinition
> id="urn:mace:dir:attribute-def:postalAddress">
>         <DataConnectorDependency requires="echo"/>
>     </SimpleAttributeDefinition>
>
>     <SimpleAttributeDefinition
> id="urn:mace:dir:attribute-def:eduPersonTargetedID">
>         <DataConnectorDependency requires="echo"/>
>     </SimpleAttributeDefinition>
>
>
>     <!-- To use these attributes, you should change the smartScope  
> value to
> match your site's domain name. -->
>
>     <SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn"
> smartScope="***OMITTED***">
>         <AttributeDependency requires="urn:mace:dir:attribute- 
> def:cn"/>
>     </SimpleAttributeDefinition>
>
>     <SimpleAttributeDefinition id="urn:mace:dir:attribute- 
> def:postalAddress"
> smartScope="***OMITTED***">
>         <DataConnectorDependency requires="echo"/>
>     </SimpleAttributeDefinition>
>
>     <SimpleAttributeDefinition
> id="urn:mace:dir:attribute-def:eduPersonTargetedID"
> smartScope="***OMITTED***">
>         <DataConnectorDependency requires="echo"/>
>     </SimpleAttributeDefinition>
>
>     <CustomDataConnector id="echo"  
> class="com.***OMITTED***.SLSConnector"/>
>
> </AttributeResolver>
>
> Any ideas on what is wrong would be appreciated.
>
> Also, about those Thread local variables: how exactly would I go about
> adding attributes to the principal in the SLSConnector.resolve()  
> method with
> thread variables declared in the ServLetFilter ?! (Thread variable  
> newbie
> here).
>
> 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: Chad La Joie 
> [mailto:]
> Sendt: 3. oktober 2006 18:04
> Til: 
>
> Emne: Re: SV: IdP Extension
>
> 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/ 
> CustomDataConnec
> tor
> > > 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