Shibboleth Developers

[Ulrich Bæch-Laursen <>]

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