Shibboleth Developers

["Rieger, Sebastian" <>]

> 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 

Thanks a lot! I thought scopes are defined in the SAML standard as I saw
them as a parameter in the saml:Attribute, sorry, my fault. The fact that
they're Shib specific clears up everything! Thanks!
I'll take a look a the code of the IdP, though from my first views it seemed
like the IdP naturally only creates Scopes but doesn't get or extract them
from a given attribute statement. I'll check that again tomorrow. Otherwise
I'll go for some XPATH statements and get the scope from the attribute
statement directly - your point...

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

...scares me a little bit ;))) I don't want to deal with different formats!
but anyway... ;)

MfG

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

 

> -----Ursprüngliche Nachricht-----
> Von: Chad La Joie 
> [mailto:]
>  
> Gesendet: Donnerstag, 11. Dezember 2008 21:19
> An: 
> 
> Betreff: Re: AW: [Shib-Dev] getting Scope from SAMLAttribute
> 
> 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
> 
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature