Shibboleth Developers

[Chad La Joie <>]

Okay, I didn't follow all of that, but that's fine.  If you have a data
connector doing an attribute query to another IdP you'll need to tear
down the attribute statement appropriately. Scopes are a Shibboleth-only
concept so you're not going to find that code in OpenSAML.  Like I said,
look at the attribute definitions that create scoped attributes in order
to see how Shibboleth creates the data structures that represent
attributes composed of values and scopes.  You'll probably also want to
look at the Scope-aware attribute encoders in order to see the different
ways in which scopes can be represented, since you'll have to deal with
them in various formats.

Rieger, Sebastian wrote:
> Hi,
> 
> thanks for the quick reply.  
> 
>> I'm not sure I understand what you're doing.  You'll need to 
>> give some more context for where that code is being executed 
> 
> ok... we created a mechanismn we call "IdP Proxy" that allows us to
> authenticate users at different IdPs. So the user selects the "Proxy IdP" in
> a federation, and logs in there (using his mail address). The domain part of
> the mail address is used as a realm, to decide which IdP to use for the real
> authentication. So let's say the user logs in as 
> 
>  then
> we send either LDAP or Shibboleth Login request to the IdP e.g. at
> idp.institute.mpg.de (we're using a filter in the Tomcat running the IdP
> Proxy to do this). In the Shib case we get an assertion which is validated
> on the "IdP Proxy" that somehow behaves like a "Java SP"... Then we get the
> attributes from idp.institute.mpg.de using a custom data connector that
> again asks idp.institute.mpg.de for the attributes of the specific user. We
> get the attributes without problems with the code I sent... but
> SAMLAttribute seems only to offer a getValues() method. For scoped
> attributes this is why we get etc. "jdoe" instead of 
> ""
> - the scope is missing in the values we get. I didn't find something like
> getScope() etc. in OpenSAML (neither in 1.1 nor 2.0?). As I get the XML
> fragment containing the saml:Attribute, I could go for XPATH though and get
> the Parameter Scope="institute.mpg.de" though. But I wanted to know if there
> is some method in the API that gives me exactly this scope
> "institute.mpg.de"... I there was something like getScope() it wouldn't be a
> big deal to append the scope to the value and get 
> ""
> return this to the data connector and use a prescoped attribute definition
> in the resolver. Without this solution all scopes that we get from the
> remote IdP are lost after resolving the attributes in the IdP proxy.
> 
> So... why do we do all this?:
> - not all of the 80 institutes of the Max-Planck-Society (MPG) will install
> and maintain their own IdP, so the "proxy" allows us to offer different
> possibilities to "connect" the identity sources (LDAP, ...) of the
> institute...
> - the IdP Proxy is placed in several federations, in these federations there
> is only one entry for the entire MPG, and the WAYF is not populated with 80
> entries for the autonomous institutes... and we don't need to struggle with
> a cascade of WAYF servers like the WWAYF e.g. in eduGAIN - discovery is
> simply done using the mail address, that the user already knows.
> 
>> or, better yet, if you want to know how the IdP works with 
>> scoped attributes than look at the attribute definitions that 
>> create such attributes.
> 
> we already configured the IdP to work with scoped attributes - no problem
> there. We just want to know how we can get the scope from attributes we
> receive from another IdP in Java. Pretty much like the SP would do to get
> the scope... 
> 
> Hope I was able to clear things up a little bit? ;))
> 
> Sebastian Rieger
> 
> --
> Dr. Sebastian Rieger
> Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen 
> Am Fassberg - 37077 Göttingen
> Fon: +49 551 201 1878 -- Fax: +49 551 201 2150
> 
> Geschäftsführer: Prof. Dr. Bernhard Neumair
> Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger
> Sitz der Gesellschaft: Göttingen
> Registergericht: Göttingen
> Handelsregister-Nr. B 598
> 
> Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des DFN
> überprüft werden:
> https://ca.gwdg.de/certs/root-DGP/deutsche-telekom-ca2-root-cert.der

-- 
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch