proxy-authentication to SP

Martin Haase Martin.Haase at
Mon May 4 04:44:23 EDT 2015

Hia Ulf,

another direction you could look into: one-tier delegation (i.e. the
"bar" SP will not ask yet another "baz" SP) is covered by the oAuth2
standard, see Delegation is actually
a main use case of oAuth2. So you could let the "foo SP" be secured
using SAML, and let it be an oAuth2 client at the same time, making the
"bar SP" actually an oAuth2 resource instead of a SAML SP. This may be
easier than the pure SAML delegation Peter mentioned.


Am 30.04.2015 um 15:00 schrieb Ulf Seltmann:
> Hello Dave, hello Peter
> thanks for your response.
> Dave, you assume right that the data is specific to each user on both
> SPs. The problem we have with your suggested approach is that "foo SP"
> has to know which users data to ask "bar SP" for. therefor we have to
> somehow implement a way of telling "foo SP" what user's data on "bar SP"
> is related to the authenticated user. Thats not only an additional
> request that has to be implemented and provided by the user but more
> importantly its a security issue that "foo SP" can ask for *any* data
> about *any* user which we are not willing to allow. 
> Peter, thanks for pointing out the "delegation" approach, so now i have
> a term to work with. :)
> ciao
> ulf

Dr. Martin Haase, Solutions Engineer

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                

phone: +49 7071 407109-6
fax:   +49 7071 407109-9  
email: martin.haase at

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2227 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the users mailing list