[OpenSAML] [OpenSAML2] Testing SAML relying party browser post profile

[Pantvaidya, Vishwajit]

I was wondering if there are any tools available for testing a browser post profile implementation at the relying party (service provider). I was planning to just take some saml xml data dumps that I have and write java code to deserialize it, sign it and send it to the service provider. Before I do that, just wanted to know if there are tools that can do it especially from the point of view of automating qa for this functionality.

 

 

- Vish.

[Brent Putman]

I don't know off-hand of any tools per se, especially that would
facilitate automated QA testing. Wouldn't be hard to write a little
script or tool as you suggested.

If you wanted to go to the trouble to test against a full SAML IdP, you
could install a Shibboleth 2.0 IdP, Internet2's open source SAML IdP
implementation, based on OpenSAML. http://shibboleth.internet2.edu/

Or you could use the public test IdP that the Shibboleth team runs
called TestShib. http://www.testshib.org/. That's primarily intended
for people testing either SP or IdP Shibboleth installations, so the
instructions there are a little Shibboleth-centric. But generally
speaking Shib IdP's interop with non-Shib SP's and vice-versa. If you
just register as an SP, and provide the right metadata when you
register, you should be able to interop with the TestShib IdP.

--Brent

[Pantvaidya, Vishwajit]

Thanks.
The test IdP seems just right. Does it let me provide my own public-private or secret keys that I generated to test my SP?

[Scott Cantor]

> The test IdP seems just right. Does it let me provide my own
public-private
> or secret keys that I generated to test my SP?

You have to supply metadata, which includes the public key. Your private key
is your business.

-- Scott

[Pantvaidya, Vishwajit]

For signatures, don't you sign with the private key and then the recipient validates with the public key? So I thought, the test IdP since it would generate a signed SAML message would need a private key to test with.

[Brent Putman]

Yes, correct about signatures.

You supply your public key to the IdP when you register, in case you want to send signed messages or do client TLS to the IdP (or have the IdP encrypt data to you in its responses).

It supplies its public key to you in the form of metadata that you can download and consume for validating signatues it generates (or for encrypting data to the IdP in your requests).  If your SP implementation doesn't directly consume SAML metadata, then just manually extract the IdP's keys and other information and store however you like.

The exchange of info between IdP and an SP is generally a 2-way thing.

[Pantvaidya, Vishwajit]

Ok - so the test IdP will sign the saml msg using its own private key and I can validate that using its public key that it gives me, right?

And if I need encryption it will encrypt the saml msg using my pub key that I give to it when I register. And my SP can decrypt it using my own private key right?

--------------------------
Sent from my BlackBerry Wireless Handheld

[Brent Putman]

Pantvaidya, Vishwajit wrote:
> Ok - so the test IdP will sign the saml msg using its own private key and I can validate that using its public key that it gives me, right?
>
>

Yes.

> And if I need encryption it will encrypt the saml msg using my pub key that I give to it when I register. And my SP can decrypt it using my own private key right?
>
>

Yes, assuming you're doing SAML 2. SAML 1 didn't support XML Encryption.

[Pantvaidya, Vishwajit]

Yes right now I am doing saml1 so encryption is not relevant - but just wanted to be clear on that as well.

Thanks a lot. I must say that so far my experience migrating to opensaml has been very smooth and troublefree, due in no small measure to the prompt help from Brent and Scott and Nate in the forums.

--------------------------
Sent from my BlackBerry Wireless Handheld


----- Original Message -----
From: Brent Putman <put...@georgetown.edu>
To: mace-open...@internet2.edu <mace-open...@internet2.edu>
Sent: Fri Nov 07 19:37:15 2008
Subject: Re: [OpenSAML] Testing SAML relying party browser post profile

[Pantvaidya, Vishwajit]

Does the test IdP let me provide a secret key as well? I am thinking secret keys would be primarily (or even only?) used in encryptions and not signatures - which means they are irrelevant for SAML1.x but could be used for encryption in SAML2.0. Is this accurate?

- Vish.

[Brent Putman]

Pantvaidya, Vishwajit wrote:
> Does the test IdP let me provide a secret key as well?

No, I don't think the TestShib IdP lets you provide a secret key. It's
just storing the info you give it in public metadata, so that's counter
to that approach. Actually, I don't believe there's any currently
defined mechanism to represent symmetric keys in a ds:KeyInfo, which is
used by SAML metadata.

> I am thinking secret keys would be primarily (or even only?) used in encryptions and not signatures - which means they are irrelevant for SAML1.x but could be used for encryption in SAML2.0. Is this accurate?
>
>

You actually can do signing with symmetric keys as well. See HMAC,
which is implemented as keyed hashing. There are several HMAC
algorithms defined for XML Signature.

Re: encryption: When you do encryption in SAML, especially if the IdP
and SP are exchanging info via SAML metadata, it is typical that you do
actually encrypt the data with a randomly generated symmetric key. That
symmetric data encryption key in turn is encrypted with the recipient's
public key (e.g. obtained from metadata) and sent along with the
encrypted data as an xenc:EncryptedKey element. Take a look at the XML
Encryption spec and relevant sections of SAML Core if you want to know
all the gory details. The OpenSAML 2 Decrypter code handles all that
for you transparently, as long as you give it the right inputs.

[Pantvaidya, Vishwajit]

 

Pantvaidya, Vishwajit wrote:

> Does the test IdP let me provide a secret key as well?

No, I don't think the TestShib IdP lets you provide a secret key.  It's

just storing the info you give it in public metadata, so that's counter

to that approach.  Actually, I don't believe there's any currently

defined mechanism to represent symmetric keys in a ds:KeyInfo, which is

used by SAML metadata.

 

[Pantvaidya, Vishwajit] So what you mean is that even with SAML2.0 there is no way to use secret keys?

 

…Re: encryption:  When you do encryption in SAML, especially if the IdP

and SP are exchanging info via SAML metadata, it is typical that you do

actually encrypt the data with a randomly generated symmetric key.  That

symmetric data encryption key in turn is encrypted with the recipient's

public key (e.g. obtained from metadata) and sent along with the

encrypted data as an xenc:EncryptedKey element.  Take a look at the XML…

 

[Pantvaidya, Vishwajit] Just to understand this, why not just encrypt with the public key? Does this provide any additional level of security (though I cannot imagine how).

 

 

 

- Vishwajit.

 

[Scott Cantor]

> [Pantvaidya, Vishwajit] So what you mean is that even with SAML2.0 there
is
> no way to use secret keys?

Yes, it's allowed.

> [Pantvaidya, Vishwajit] Just to understand this, why not just encrypt with
> the public key? Does this provide any additional level of security (though
I
> cannot imagine how).

RSA encryption is many times as expensive. You never bulk encrypt with RSA.

-- Scott

[Brent Putman]

Pantvaidya, Vishwajit wrote:
>
> [Pantvaidya, Vishwajit] So what you mean is that even with SAML2.0 there is no way to use secret keys?
>
>

No, SAML doesn't restrict things in this way at all. Symmetric keys are
perfectly fine for SAML 2, and for XML Encryption in general. However,
you would need to manage the key exchange out-of-band in that case, and
unless the key is known from context, mange things like key identifiers
for identifying the encryption key in the ds:KeyInfo by reference
(rather than by value).

The Java OpenSAML code does support symmetric keys for XML Encryption,
as long as you supply the right inputs on the encryption and/or
decryption side. It's more of an advanced use case, however.

>
> ...Re: encryption: When you do encryption in SAML, especially if the IdP

>
> and SP are exchanging info via SAML metadata, it is typical that you do
>
> actually encrypt the data with a randomly generated symmetric key. That
>
> symmetric data encryption key in turn is encrypted with the recipient's
>
> public key (e.g. obtained from metadata) and sent along with the
>

> encrypted data as an xenc:EncryptedKey element. Take a look at the XML...

>
>
>
> [Pantvaidya, Vishwajit] Just to understand this, why not just encrypt with the public key? Does this provide any additional level of security (though I cannot imagine how).
>

One reason is performance. The asymmetric ciphers (e.g. RSA) tend to be
about 1000 to 10,000 times slower than symmetric ciphers of comparable
strength (i.e. 3 or 4 orders of magnitude). That's a big hit. So the
idea is to encrypt a small amount of data (a symmetric key) with the
public key to lessen that hit.

And another is pragmatic: Because of the above, I believe that XML
Encryption does not even define algorithm URI's for say RSA for bulk
data encryption. You'd have to define cipher modes and so on, if you
want to encrypt data larger than the maximum encryptable block size for
the algorithm. For RSA, that max block size is a little less than the
modulus size, e.g. for a 2048 bit RSA key, you can encrypt slightly less
than 2k of data. That's more than enough for encrypting a symmetric key
(e.g. AES 256 bit), but not nearly enough for say a medium to large
sized SAML Assertion.

Note that that's how most all use of asymmetric ciphers for encryption
works, e.g. SSL/TLS. In that case, you either use the remote peer's
public key to encrypt randomly generated temporal session symmetric
keys, or you just use the public key to authenticate the peer, and then
negotiate the session key(s) with a key agreement protocol, e.g.
Diffie-Hellman. The symmetric session keys are then used to encrypt
data on the wire.

--Brent

[Pantvaidya, Vishwajit]

> [Pantvaidya, Vishwajit] Just to understand this, why not just encrypt with the public key? Does this provide any additional level of security (though I cannot imagine how).

 

One reason is performance.  The asymmetric ciphers (e.g. RSA) tend to be

about 1000 to 10,000 times slower than symmetric ciphers of comparable

strength (i.e. 3 or 4 orders of magnitude).  That's a big hit.  So the

idea is to encrypt a small amount of data (a symmetric key) with the

public key to lessen that hit.

 

And another is pragmatic:  Because of the above, I believe that XML

Encryption does not even define algorithm URI's for say RSA for bulk

data encryption.  You'd have to define cipher modes and so on, if you

want to encrypt data larger than the maximum encryptable block size for

the algorithm.  For RSA, that max block size is a little less than the

modulus size, e.g. for a 2048 bit RSA key, you can encrypt slightly less

than 2k of data.  That's more than enough for encrypting a symmetric key

(e.g. AES 256 bit), but not nearly enough for say a medium to large

sized SAML Assertion...

 

[Pantvaidya, Vishwajit] Brent, thanks a lot for the insight. You mentioned earlier that secret keys are also used to sign SAML responses. Is that also done in a similar way i.e. use a randomly generated secret key to sign and then encrypt the secret key using a public key?

 

 

[Brent Putman]

Pantvaidya, Vishwajit wrote:
>
> [Pantvaidya, Vishwajit] Brent, thanks a lot for the insight. You mentioned earlier that secret keys are also used to sign SAML responses.

Well, they *can* be, via HMAC signing algorithms. Most people I think
tend to instead still use public key crypto for XML signatures for the
common use cases, for the same reasons that public key crypto was
developed: solving the key exchange problem.

Signing with a symmetric key via HMAC just mixes bits of the shared
symmetric key material into the data that is digested, so that when the
signature is validated the recipient has to mix in the same key bits in
order to successfully validate it. AFAIK, it doesn't even use the
associated symmetric cipher algorithm. That is, the key isn't use as a
"key" per se, but rather just "shared secret bits".

> Is that also done in a similar way i.e. use a randomly generated secret key to sign and then encrypt the secret key using a public key?
>
>

No, when you sign with a private key via asymmetric crypto, there is no
symmetric key involved, at least for the algorithms I'm familiar with.
The amount of data that is encrypted to produce a signature is usually
small, the size of the output of a hash algorithm, e.g. 128 or 160 bits,
or maybe up to 256 or 512 bits with some of the newer SHA variants.
That's small enough to be encrypted as a single block by even a 512 or
1024 bit RSA key, for example.

--Brent

[Pantvaidya, Vishwajit]

For using the test IdP service at testshib.org, I need to register my service provider with it - and when I try that I get "Entry could not be stored due to a servlet error ".

I gave the following input:

1. name of the SP machine - for this I provided the external ip address of the machine (instead of the machine name) on which my SP server runs. Is that okay?

2. the SP's certificate
- since my SP installtion does not user Shibboleth, it did not generate any certificate. So I left this empty. Is this the problem?
- what is this certificate used for?

> -----Original Message-----
> From: Pantvaidya, Vishwajit [mailto:vpan...@selectica.com]

> Sent: Friday, November 07, 2008 3:25 PM
> To: mace-open...@internet2.edu

> Subject: RE: [OpenSAML] [OpenSAML2] Testing SAML relying party browser
> post profile
>

[Scott Cantor]

> 1. name of the SP machine - for this I provided the external ip address of
> the machine (instead of the machine name) on which my SP server runs. Is
> that okay?

No, it's not.

> 2. the SP's certificate
> - since my SP installtion does not user Shibboleth, it did not
> generate any certificate. So I left this empty. Is this the problem?

Probably.

> - what is this certificate used for?

Authentication of back-channels mostly, and a container for encryption keys
in the metadata.

-- Scott

[Pantvaidya, Vishwajit]

I registered my SP with testshib. Now as I understand, the way to test a Shib SP with the test IdP is to
- deploy the generated configuration file to the Shib SP
- then access the SP's content located at https://yourhost.org/secure/
This will redirect to the testIdP which after logging in will release attributes to the Shib SP being tested.

Instead of the above, I would just like to access the testshib IdP and upon logging in there would like the IdP to send an assertion to my (non-Shib) SP with the attributes. Is this possible?

Presuming my desired flow is possible and assuming that the normal flow was all driven by the configuration xml driven, I:
- found out the idp url https://idp.testshib.org/idp/shibboleth from the configuration xml
- from the doc at that url, I got the url for SAML2 POST as https://idp.testshib.org/idp/profile/SAML2/POST/SSO. So I tried replacing the SAML2 with SAML1 but neither worked.

So is it at all possible to just go to the test idp url and provide my provider id and login to trigger the browser post of the assertion to my SP?

- Vish.

> -----Original Message-----
> From: Scott Cantor [mailto:cant...@osu.edu]

> Sent: Tuesday, December 02, 2008 8:47 AM
> To: mace-open...@internet2.edu
> Subject: RE: [OpenSAML] [OpenSAML2] Testing SAML relying party browser
> post profile
>

[Scott Cantor]

> Instead of the above, I would just like to access the testshib IdP and
upon
> logging in there would like the IdP to send an assertion to my (non-Shib)
SP
> with the attributes. Is this possible?

No, not with SAML 2 anyway. We don't support IdP-initiated SSO except with
the legacy Shibboleth/SAML1 option.

> - from the doc at that url, I got the url for SAML2 POST as
> https://idp.testshib.org/idp/profile/SAML2/POST/SSO. So I tried replacing
> the SAML2 with SAML1 but neither worked.

That works fine, but only if you, well, do that. That's a SAML endpoint and
you have to give it a SAML request.

> So is it at all possible to just go to the test idp url and provide my
> provider id and login to trigger the browser post of the assertion to my
SP?

Only with legacy requests and SAML 1.1 responses.

-- Scott

[Pantvaidya, Vishwajit]

Ok - so I need to use testshib 1.3 instead of 2.0?
If yes, I suppose their should be no problem for my saml 1.1 sp that uses opensaml2.0 to process the saml1.1 assertion from testshib 1.3?

--------------------------
Sent from my BlackBerry Wireless Handheld


----- Original Message -----

[Chad La Joie]

Testhib2 supports all the old profiles. So you can 2, but just use the
old Shib SSO profile with it.

--
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
chad....@switch.ch, http://www.switch.ch

[Pantvaidya, Vishwajit]

By profiles, do you mean profiles as in "browser post profile" or something else?

My goal is to POST a test saml1.1 assertion to my non-Shibboleth SP (implemented using OpenSAML2).

I have already:
- registered with openid
- registered my SP with testshib

So is there anyway that I can post an assertion using testshib to my SP?
If yes, is there a URL/application that I need to use to trigger this post?
If no, will having a full shibboleth deployment help me do this?

- Vish.

> -----Original Message-----
> From: Chad La Joie [mailto:chad....@switch.ch]
>
> Testhib2 supports all the old profiles. So you can 2, but just use the
> old Shib SSO profile with it.
>
> Pantvaidya, Vishwajit wrote:
> > Ok - so I need to use testshib 1.3 instead of 2.0?
> > If yes, I suppose their should be no problem for my saml 1.1 sp that
> uses opensaml2.0 to process the saml1.1 assertion from testshib 1.3?
> >
> >

> > ----- Original Message -----
> > From: Scott Cantor <cant...@osu.edu>
> >

[Brent Putman]

Pantvaidya, Vishwajit wrote:
> By profiles, do you mean profiles as in "browser post profile" or something else?
>

No, not exactly. In SAML 1.1. Browser POST profile only covers the POST
to the SP. There was no request defined into the IdP. IdP initiated
was assumed. Shibboleth 1.x extended this profile with a simple
SP-initiated protocol, comprised of a GET with query parameters. The
protocol/profile you want is defined in:

http://shibboleth.internet2.edu/docs/internet2-mace-shibboleth-arch-protocols-200509.pdf

For quickstart see specifically section 3.1.1. It's really 3 GET query
parameters indicated there.

> My goal is to POST a test saml1.1 assertion to my non-Shibboleth SP (implemented using OpenSAML2).
>
> I have already:
> - registered with openid
> - registered my SP with testshib
>
> So is there anyway that I can post an assertion using testshib to my SP?
> If yes, is there a URL/application that I need to use to trigger this post?
>

Yes. With Shibboleth 2.x (and TestShib 2) the default IdP endpoint for
the above Shibboleth SAML 1.x protocol would be:
https://idp.testshib.org/idp/profile/Shibboleth/SSO

--Brent

[Brent Putman]

Brent Putman wrote:

If yes, is there a URL/application that I need to use to trigger this post?
  
    

Yes.  With Shibboleth 2.x (and TestShib 2) the default IdP endpoint for
the above Shibboleth SAML 1.x protocol would be: 
https://idp.testshib.org/idp/profile/Shibboleth/SSO
  

And in case you were wondering, you can see how all the default Shibboleth 2.x IdP  endpoints map to binding and profile combinations here:

http://svn.middleware.georgetown.edu/view/java-idp/branches/REL_2/src/installer/resources/conf-tmpl/handler.xml?revision=2753&view=markup

[Pantvaidya, Vishwajit]

Thanks. Based on this, I tried the following browser requests:

https://idp.testshib.org/idp/profile/Shibboleth/SSO?providerId=https%3A%2F%2Fvishsjlaptop.selectica.com%2Fshibboleth%2Ftestshib%2Fsp&shire=http%3A%2F%2Fvishsjlaptop.selectica.com&target=login.jsp
(i.e. providerId=https://vishsjlaptop.selectica.com/shibboleth/testshib/sp, shire=http://vishsjlaptop.selectica.com/, target=login.jsp)

and

https://idp.testshib.org/idp/profile/Shibboleth/SSO?providerId=https%3A%2F%2F64.161.158.31%2Fshibboleth%2Ftestshib%2Fsp&shire=http%3A%2F%2F64.161.158.31&target=login.jsp

But I get "Error Message: No peer endpoint available to which to send SAML response" and the idp process log has following messages:

21:51:54.362 DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:126] - Looking up relying party configuration for https://64.161.158.31/shibboleth/testshib/sp
21:51:54.363 DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:132] - No custom relying party configuration found for https://64.161.158.31/shibboleth/testshib/sp, looking up configuration based on metadata groups.
21:51:54.364 DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:155] - No custom or group-based relying party configuration found for https://64.161.158.31/shibboleth/testshib/sp. Using default relying party configuration.
21:51:54.365 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:78] - Selecting endpoint from metadata corresponding to provided ACS URL: http://64.161.158.31
21:51:54.365 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:82] - Relying party role contains 4 endpoints
21:51:54.366 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:101] - No endpoint meets selection criteria for SAML entity https://64.161.158.31/shibboleth/testshib/sp
21:51:54.367 ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:396] - No return endpoint available for relying party https://64.161.158.31/shibboleth/testshib/sp
21:51:54.368 ERROR [edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet:85] - Error processing profile request
edu.internet2.middleware.shibboleth.common.profile.ProfileException: No peer endpoint available to which to send SAML response

Does this mean it tried to send a saml request to my SP? Or is their something missing in my configuration?

> -----Original Message-----
> From: Brent Putman [mailto:put...@georgetown.edu]
>

[Brent Putman]

In looking at the metadata, I see that you have registered in both
TestShib 1 and TestShib 2, in one of them both by FQDN and IP address.
I'd suggest getting rid of all but one of those, just to avoid
confusion. I think you can delete your own entries via the "Edit"
operation. If not, maybe Nate can assist in that. Looks like from the
test below you were using the IP-address-named one in the TestShib 1
metadata.

Pantvaidya, Vishwajit wrote:
> Thanks. Based on this, I tried the following browser requests:
>
> https://idp.testshib.org/idp/profile/Shibboleth/SSO?providerId=https%3A%2F%2Fvishsjlaptop.selectica.com%2Fshibboleth%2Ftestshib%2Fsp&shire=http%3A%2F%2Fvishsjlaptop.selectica.com&target=login.jsp
> (i.e. providerId=https://vishsjlaptop.selectica.com/shibboleth/testshib/sp, shire=http://vishsjlaptop.selectica.com/, target=login.jsp)
>

Yeah, your shire parameter there isn't correct, or at least doesn't jibe
with metadata. That should:
1) be the endpoint to which the POST profile will post the SAML
response. Don't know what that is in your app. Maybe
http://vishsjlaptop.selectica.com/ is correct, but that looks a little
suspect. Probably should be a explicit path there.
2) it needs to match one of the AssertionConsumerService endpoints for
the Browser POST binding in your metadata entry. Find the effective
metadata entry that you are using (easier if you get rid of all but one
of them) and in your EntityDescriptor/AssertionConsumerService entries'
Location attribute, make sure they match your SP implementation's
endpoint. The default values that are generated are for a Shibboleth
SP, certainly not the same as your SP. Here's what one of your entries
has, for example

<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"

Location="https://vishsjlaptop.selectica.com/Shibboleth.sso/SAML/POST"
index="6"/>
<md:AssertionConsumerService
Binding="urn:oasis:names:tc:SAML:1.1:profiles:browser-post"

Location="http://vishsjlaptop.selectica.com/Shibboleth.sso/SAML/POST"
index="7"/>

What you supply in metadata must match what you specify in the shire
parameter, and must of course match where your SP actually accepts the
posted response.

Shibboleth as you may have noticed is based heavily on the use of SAML
metadata.

> 21:51:54.365 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:78] - Selecting endpoint from metadata corresponding to provided ACS URL: http://64.161.158.31
> 21:51:54.365 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:82] - Relying party role contains 4 endpoints
> 21:51:54.366 DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOEndpointSelector:101] - No endpoint meets selection criteria for SAML entity https://64.161.158.31/shibboleth/testshib/sp
>

Yeah, see you have 4 ACS endpoints in the entry, but none of them are
"http://vishsjlaptop.selectica.com/", so it can't validate that that is
a valid ACS endpoint for the entity ID that you are claiming to be.

> 21:51:54.367 ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:396] - No return endpoint available for relying party https://64.161.158.31/shibboleth/testshib/sp
> 21:51:54.368 ERROR [edu.internet2.middleware.shibboleth.common.profile.ProfileRequestDispatcherServlet:85] - Error processing profile request
> edu.internet2.middleware.shibboleth.common.profile.ProfileException: No peer endpoint available to which to send SAML response
>
> Does this mean it tried to send a saml request to my SP? Or is their something missing in my configuration?
>

It's trying to process the request, but it can't complete successfully
because of the endpoint mismatch. But I think you're getting close. :-)

[Pantvaidya, Vishwajit]

> -----Original Message-----
> From: Brent Putman [mailto:put...@georgetown.edu]
> Sent: Wednesday, December 03, 2008 8:44 PM
>
> I'd suggest getting rid of all but one of those, just to avoid
> confusion. I think you can delete your own entries via the "Edit"

[Pantvaidya, Vishwajit] I deleted the 2 TestShib2 profiles.

>
> Pantvaidya, Vishwajit wrote:
> > Thanks. Based on this, I tried the following browser requests:
> >
> >
> https://idp.testshib.org/idp/profile/Shibboleth/SSO?providerId=https%3A%2F
> %2Fvishsjlaptop.selectica.com%2Fshibboleth%2Ftestshib%2Fsp&shire=http%3A%2
> F%2Fvishsjlaptop.selectica.com&target=login.jsp
> > (i.e.
> providerId=https://vishsjlaptop.selectica.com/shibboleth/testshib/sp,
> shire=http://vishsjlaptop.selectica.com/, target=login.jsp)
> >
>
> Yeah, your shire parameter there isn't correct, or at least doesn't jibe
> with metadata. That should:
> 1) be the endpoint to which the POST profile will post the SAML
> response. Don't know what that is in your app. Maybe
> http://vishsjlaptop.selectica.com/ is correct, but that looks a little
> suspect. Probably should be a explicit path there.

[Pantvaidya, Vishwajit] The endpoint is correct - that's where my Sp is available. I think I have forgotten the login.jsp at the end. I will add that.

> 2) it needs to match one of the AssertionConsumerService endpoints for
> the Browser POST binding in your metadata entry. Find the effective
> metadata entry that you are using (easier if you get rid of all but one
> of them) and in your EntityDescriptor/AssertionConsumerService entries'
> Location attribute, make sure they match your SP implementation's
> endpoint. The default values that are generated are for a Shibboleth
> SP, certainly not the same as your SP. Here's what one of your entries
> has, for example
>
>
> <md:AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-
> post"
>
> Location="https://vishsjlaptop.selectica.com/Shibboleth.sso/SAML/POST"
> index="6"/>
> <md:AssertionConsumerService
> Binding="urn:oasis:names:tc:SAML:1.1:profiles:browser-
> post"
>
> Location="http://vishsjlaptop.selectica.com/Shibboleth.sso/SAML/POST"
> index="7"/>
>

[Pantvaidya, Vishwajit] Didn't know that testshib adds that at the end. Thanks. I will edit that to match my SP. Will let you know how that goes.

[Pantvaidya, Vishwajit]

Thanks Brent. Back from vacation and fresh, I tried with the changed URL based on your suggestions and I was able to receive the response from testshib on my server. Now I will try to run it through the entire logic and see how that goes.

- Vish.

> -----Original Message-----
> From: Pantvaidya, Vishwajit [mailto:vpan...@selectica.com]

> Sent: Thursday, December 04, 2008 9:12 PM
> To: mace-open...@internet2.edu
> Subject: RE: [OpenSAML] Testing SAML relying party browser post profile
>
>
>

[Pantvaidya, Vishwajit]

Finally I got back to this and am facing a problem with getting testshib to use my key. I pasted my DSA key into my profile so that it looks like this:

<?xml version="1.0" encoding="UTF-16"?>
<md:EntityDescriptor entityID="https://64.161.158.31/shibboleth/testshib/sp" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:2.0:protocol" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:X509Certificate xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
MIIDDzCCAs0CBEk1/EQwCwYHKoZIzjgEAwUAMG0xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEQ
MA4GA1UEBxMHU2FuSm9zZTESMBAGA1UEChMJU2VsZWN0aWNhMQwwCgYDVQQLEwNTQ00xHTAbBgNV
BAMTFFZpc2h3YWppdCBQYW50dmFpZHlhMB4XDTA4MTIwMzAzMjU1NloXDTA5MDMwMzAzMjU1Nlow
bTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRAwDgYDVQQHEwdTYW5Kb3NlMRIwEAYDVQQKEwlT
ZWxlY3RpY2ExDDAKBgNVBAsTA1NDTTEdMBsGA1UEAxMUVmlzaHdhaml0IFBhbnR2YWlkeWEwggG4
MIIBLAYHKoZIzjgEATCCAR8CgYEA/X9TgR11EilS30qcLuzk5/YRt1I870QAwx4/gLZRJmlFXUAi
UftZPY1Y+r/F9bow9subVWzXgTuAHTRv8mZgt2uZUKWkn5/oBHsQIsJPu6nX/rfGG/g7V+fGqKYV
DwT7g/bTxR7DAjVUE1oWkTL2dfOuK2HXKu/yIgMZndFIAccCFQCXYFCPFSMLzLKSuYKi64QL8Fgc
9QKBgQD34aCF1ps93su8q1w2uFe5eZSvu/o66oL5V0wLPQeCZ1FZV4661FlP5nEHEIGAtEkWcSPo
TCgWE7fPCTKMyKbhPBZ6i1R8jSjgo64eK7OmdZFuo38L+iE1YvH7YnoBJDvMpPG+qFGQiaiD3+Fa
5Z8GkotmXoB7VSVkAUw7/s9JKgOBhQACgYEA2+ohVrn25xpzdVQgVFsxs+v+4lTa616BvaUxbqeg
rr8DPz7Jo7K8ZAPWSMgEmT17eH2zXEuH2/03k2As67GbhhfLNa+p98eE+szPVLJEFBgche9hXhg7
ukyUmruWrUQqnfCgOy6je7wBX0Aqu+jGmD5WQ8+gkeeLkVbsqxSMBLkwCwYHKoZIzjgEAwUAAy8A
MCwCFE2bIZayEWWIbJB3X3Cm4kCRYN15AhQsZD0jQfV4+CxsEJ1IEuMltnjtZA==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</md:NameIDFormat>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://64.161.158.31/" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://64.161.158.31/Shibboleth.sso/SAML/Artifact" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="http://64.161.158.31/" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="http://64.161.158.31/Shibboleth.sso/SAML/Artifact" index="4"/>
</md:SPSSODescriptor>
...
</md:EntityDescriptor>

When I get the saml response from testshib it looks like this:

<samlp:Response IssueInstant="2009-03-20T22:09:28.528Z" MajorVersion="1" MinorVersion="1" Recipient="http://64.161.158.31/" ResponseID="_546f4fc45c6a7cb8ddd11836497a56d0" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_546f4fc45c6a7cb8ddd11836497a56d0">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="ds saml samlp" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>r78bWVR3/jfHpRFhnLuJuGeyqoE=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>I5RN2IMnOv1L02wOz4QJEb3OXg6cy5OZpvNEWI08ivutqUIlexyKs/ZwtGx+y9kAsKRZgvlPcby1
VSsCkKs/EPf7boElLZDYnIctCgM+Uyf45jeDEWGM+4VEZZbaJ4DIY+Cm4wD2zIRr2KzN6totCDkY
3hUE3eRTjQPQinQA7yXVib8XdgnVWfqdA1oAeZriCa1TaDCOW/1my2bbd6o/ZUH402wj0HG1gnr9
tAp2M0tbB42k+lBxKRqhq0lpSfmzposd8AcN69ztQ/sZhasN2kj1dk8OdFMokegm037jbrT3/rdg
otfDqEGTSv/B8jo04dKB4zlgQzONg7Jyu9bJdw==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIEDjCCAvagAwIBAgIBADANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJVUzEVMBMGA1UECBMM
UGVubnN5bHZhbmlhMRMwEQYDVQQHEwpQaXR0c2J1cmdoMREwDwYDVQQKEwhUZXN0U2hpYjEZMBcG
A1UEAxMQaWRwLnRlc3RzaGliLm9yZzAeFw0wNjA4MzAyMTEyMjVaFw0xNjA4MjcyMTEyMjVaMGcx
CzAJBgNVBAYTAlVTMRUwEwYDVQQIEwxQZW5uc3lsdmFuaWExEzARBgNVBAcTClBpdHRzYnVyZ2gx
ETAPBgNVBAoTCFRlc3RTaGliMRkwFwYDVQQDExBpZHAudGVzdHNoaWIub3JnMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEArYkCGuTmJp9eAOSGHwRJo1SNatB5ZOKqDM9ysg7CyVTDClcp
u93gSP10nH4gkCZOlnESNgttg0r+MqL8tfJC6ybddEFB3YBo8PZajKSe3OQ01Ow3yT4I+Wdg1tsT
pSge9gEz7SrC07EkYmHuPtd71CHiUaCWDv+xVfUQX0aTNPFmDixzUjoYzbGDrtAyCqA8f9CN2txI
fJnpHE6q6CmKcoLADS4UrNPlhHSzd614kR/JYiks0K4kbRqCQF0Dv0P5Di+rEfefC6glV8ysC8dB
5/9nb0yh/ojRuJGmgMWHgWk6h0ihjihqiu4jACovUZ7vVOCgSE5Ipn7OIwqd93zp2wIDAQABo4HE
MIHBMB0GA1UdDgQWBBSsBQ869nh83KqZr5jArr4/7b+QazCBkQYDVR0jBIGJMIGGgBSsBQ869nh8
3KqZr5jArr4/7b+Qa6FrpGkwZzELMAkGA1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTET
MBEGA1UEBxMKUGl0dHNidXJnaDERMA8GA1UEChMIVGVzdFNoaWIxGTAXBgNVBAMTEGlkcC50ZXN0
c2hpYi5vcmeCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAjR29PhrCbk8qLN5M
FfSVk98t3CT9jHZoYxd8QMRLI4j7iYQxXiGJTT1FXs1nd4Rha9un+LqTfeMMYqISdDDI6tv8iNpk
OAvZZUosVkUo93pv1T0RPz35hcHHYq2yee59HJOco2bFlcsH8JBXRSRrJ3Q7Eut+z9uo80JdGNJ4
/SJy5UorZ8KazGj16lfJhOBXldgrhppQBb0Nq6HKHguqmwRfJ+WkxemZXzhediAjGeka8nz8Jjwx
pUjAiSWYKLtJhGEaTqCYxCCX2Dw+dOTqUzHOZ7WKv4JXPK5G/Uhr8K/qhmFT2nIQi538n6rVYLeW
j8Bbnl+ev0peYzxFyF5sQA==</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
...
</samlp:Response>

So it seems like it is not using my key from the profile. Am I doing anything wrong here?

Also I see that it is not sending any attributes in the assertion. Can I configure my profile to have it send those?

[Brent Putman]

Pantvaidya, Vishwajit wrote:
> Finally I got back to this and am facing a problem with getting testshib to use my key. I pasted my DSA key into my profile so that it looks like this:
>
>

More below, but the key that you give the IdP would only be used by it
for validating signatures on signed messages you send, or on validating
certs that you present on client TLS.

> When I get the saml response from testshib it looks like this:
>
>

Just to confirm: you are intending to do SAML 1.1, right, not SAML 2?

>
> So it seems like it is not using my key from the profile. Am I doing anything wrong here?
>

The IdP is signing the response with its key, not yours. You need to
validate the signature with the IdP's key, which you obtain via some
out-of-band mechanism, for example by getting the metadata that it
publishes about itself.

> Also I see that it is not sending any attributes in the assertion. Can I configure my profile to have it send those?
>

In Shibboleth with SAML 1, the default is to not send an attribute
statement in the SSO assertion, because in the absence of encryption
support in SAML 1, those would be in the clear and that's an undesirable
default. Instead the SP is expected to do an AttributeQuery to the
IdP's AttributeAuthority using the Subject from the SSO assertion. It
*can* be configured to send attributes on SSO in SAML 1, but I'm not
sure whether or how TestShib in particular can be requested to be
configured to do that for a particular SP. Nate can hopefully tell us
if that's possible

FYI, the Shib IdP default on SAML 2 SSO is to send an encrypted
Assertion, since SAML supports XML Encryption. That can also be changed
- either the default or on a relying-party specific basic - to not
encrypt and/or not include the attribute statement at all. For that it
needs your encryption key, whcih btw can't be DSA b/c that doesn't
support encryption. Pretty much have to use RSA for that.

--Brent

[Pantvaidya, Vishwajit]

-----Original Message-----
From: Brent Putman [mailto:put...@georgetown.edu]

Sent: Friday, March 20, 2009 4:48 PM
To: mace-open...@internet2.edu

Subject: Re: [OpenSAML] Testing SAML relying party browser post profile

Just to confirm: you are intending to do SAML 1.1, right, not SAML 2?

[Pantvaidya, Vishwajit] Correct.

>
> So it seems like it is not using my key from the profile. Am I doing anything wrong here?
>

The IdP is signing the response with its key, not yours. You need to
validate the signature with the IdP's key, which you obtain via some
out-of-band mechanism, for example by getting the metadata that it
publishes about itself.

[Pantvaidya, Vishwajit] Ok thanks. I changed my code to do that. Now as I understand, a key in base64binary format should be wrapped in the "----BEGIN KEY-----" "--------END KEY-------" signature. The saml I get has the key as:

<ds:X509Certificate>MIIEDjCCAvagAwIBAgIBADANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJVUzEVMBMGA1UECBMM
UGVubnN5bHZhbmlhMRMwEQYDVQQHEwpQaXR0c2J1cmdoMREwDwYDVQQKEwhUZXN0U2hpYjEZMBcG
A1UEAxMQaWRwLnRlc3RzaGliLm9yZzAeFw0wNjA4MzAyMTEyMjVaFw0xNjA4MjcyMTEyMjVaMGcx
CzAJBgNVBAYTAlVTMRUwEwYDVQQIEwxQZW5uc3lsdmFuaWExEzARBgNVBAcTClBpdHRzYnVyZ2gx
ETAPBgNVBAoTCFRlc3RTaGliMRkwFwYDVQQDExBpZHAudGVzdHNoaWIub3JnMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEArYkCGuTmJp9eAOSGHwRJo1SNatB5ZOKqDM9ysg7CyVTDClcp
u93gSP10nH4gkCZOlnESNgttg0r+MqL8tfJC6ybddEFB3YBo8PZajKSe3OQ01Ow3yT4I+Wdg1tsT
pSge9gEz7SrC07EkYmHuPtd71CHiUaCWDv+xVfUQX0aTNPFmDixzUjoYzbGDrtAyCqA8f9CN2txI
fJnpHE6q6CmKcoLADS4UrNPlhHSzd614kR/JYiks0K4kbRqCQF0Dv0P5Di+rEfefC6glV8ysC8dB
5/9nb0yh/ojRuJGmgMWHgWk6h0ihjihqiu4jACovUZ7vVOCgSE5Ipn7OIwqd93zp2wIDAQABo4HE
MIHBMB0GA1UdDgQWBBSsBQ869nh83KqZr5jArr4/7b+QazCBkQYDVR0jBIGJMIGGgBSsBQ869nh8
3KqZr5jArr4/7b+Qa6FrpGkwZzELMAkGA1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTET
MBEGA1UEBxMKUGl0dHNidXJnaDERMA8GA1UEChMIVGVzdFNoaWIxGTAXBgNVBAMTEGlkcC50ZXN0
c2hpYi5vcmeCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAjR29PhrCbk8qLN5M
FfSVk98t3CT9jHZoYxd8QMRLI4j7iYQxXiGJTT1FXs1nd4Rha9un+LqTfeMMYqISdDDI6tv8iNpk
OAvZZUosVkUo93pv1T0RPz35hcHHYq2yee59HJOco2bFlcsH8JBXRSRrJ3Q7Eut+z9uo80JdGNJ4
/SJy5UorZ8KazGj16lfJhOBXldgrhppQBb0Nq6HKHguqmwRfJ+WkxemZXzhediAjGeka8nz8Jjwx
pUjAiSWYKLtJhGEaTqCYxCCX2Dw+dOTqUzHOZ7WKv4JXPK5G/Uhr8K/qhmFT2nIQi538n6rVYLeW
j8Bbnl+ev0peYzxFyF5sQA==</ds:X509Certificate>

How do I load it? Right now I am manually adding the begin key, end key wrappers and the signature validation works fine.

> Also I see that it is not sending any attributes in the assertion. Can I configure my profile to have it send those?
>

In Shibboleth with SAML 1, the default is to not send an attribute
statement in the SSO assertion, because in the absence of encryption
support in SAML 1, those would be in the clear and that's an undesirable
default. Instead the SP is expected to do an AttributeQuery to the
IdP's AttributeAuthority using the Subject from the SSO assertion. It
*can* be configured to send attributes on SSO in SAML 1, but I'm not
sure whether or how TestShib in particular can be requested to be
configured to do that for a particular SP. Nate can hopefully tell us
if that's possible

[Pantvaidya, Vishwajit] Ok thanks. If the request is https, this should be fine right? Anyway, if tesshib does not do it, I would need to figure out another way of doing it.

FYI, the Shib IdP default on SAML 2 SSO is to send an encrypted
Assertion, since SAML supports XML Encryption. That can also be changed
- either the default or on a relying-party specific basic - to not
encrypt and/or not include the attribute statement at all. For that it
needs your encryption key, whcih btw can't be DSA b/c that doesn't
support encryption. Pretty much have to use RSA for that.

[Pantvaidya, Vishwajit] This info will be very useful since our immediate next project after OpenSAML migration completes is to upgrade to SAML2. Thanks a lot.

--Brent

[Brent Putman]

Pantvaidya, Vishwajit wrote:
>
>
>
> [Pantvaidya, Vishwajit] Ok thanks. I changed my code to do that. Now as I understand, a key in base64binary format should be wrapped in the "----BEGIN KEY-----" "--------END KEY-------" signature. The saml I get has the key as:
>
>

> How do I load it? Right now I am manually adding the begin key, end key wrappers and the signature validation works fine.
>

There are a couple examples of signature verification here:

https://spaces.internet2.edu/display/OpenSAML/OSTwoUserManJavaDSIG

There are various helper methods in KeyInfoHelper and SecurityHelper for
translating between representations of keys and the Credential object
used as a key wrapper class in the OpenSAML API.

Note that you *can not* simply use the key that is present in the
Signature KeyInfo. An attacker could substitute their own key there.
You have to validate the signature using trusted information that is
obtained out-of-band, e.g. either the key itself or PKIX trust chains +
trusted name information expected to be bound in the validation cert.

One way to do that out-of-band exchange of key information is with SAML
metadata, which the Shibboleth software pretty much requires and relies
on exclusively.

>
> [Pantvaidya, Vishwajit] Ok thanks. If the request is https, this should be fine right?

Well, even if browser communication with both the IdP and SP is https,
it's still unencrypted in the browser, and might be left lying around in
browser cache or history. Many consider that undesirable, some do not.
We leave it up to the deployer in Shibboleth to decide, but default to
it not being fine.

> Anyway, if tesshib does not do it, I would need to figure out another way of doing it.
>

Well, if TestShib won't let you do it, then you could stand up your own
IdP for testing purposes, and then you can configure it do whatever you
want. Also, I'm not sure what attributes the TestShib IdP exposes,
probably some hardcoded things for testing. If you want specific
attributes and/or values, again you'd probably need to stand up a test
IdP and pull whatever data you want into the attribute resolver. It's
very flexible - generated attributes, LDAP, RDBMS, transformations of
any of the above, etc.

[Pantvaidya, Vishwajit]

________________________________________
From: Brent Putman [put...@georgetown.edu]
Sent: Friday, March 20, 2009 5:41 PM

To: mace-open...@internet2.edu
Subject: Re: [OpenSAML] Testing SAML relying party browser post profile

Note that you *can not* simply use the key that is present in the

Signature KeyInfo. An attacker could substitute their own key there.
You have to validate the signature using trusted information that is
obtained out-of-band, e.g. either the key itself or PKIX trust chains +
trusted name information expected to be bound in the validation cert.

One way to do that out-of-band exchange of key information is with SAML
metadata, which the Shibboleth software pretty much requires and relies
on exclusively.

[Pantvaidya, Vishwajit] Ok thanks - for now I am using the keyinfo without all this verification only for testing purposes. Ultimately, I expect to have the IdP sender's key beforehand so I will never refer it from the message.

>

Well, if TestShib won't let you do it, then you could stand up your own
IdP for testing purposes, and then you can configure it do whatever you
want. Also, I'm not sure what attributes the TestShib IdP exposes,
probably some hardcoded things for testing. If you want specific
attributes and/or values, again you'd probably need to stand up a test
IdP and pull whatever data you want into the attribute resolver. It's
very flexible - generated attributes, LDAP, RDBMS, transformations of
any of the above, etc.

[Pantvaidya, Vishwajit] About sending AttributeQuery to the IdP that you mentioned earlier, is there any existing sample code that I could user to jumpstart this. I expect this will be used only when testing using TestShib. Finally all other saml responses that I process are expected to send specific attributes.

[Pantvaidya, Vishwajit]

-----Original Message-----
From: Brent Putman [mailto:put...@georgetown.edu]

Sent: Friday, March 20, 2009 4:48 PM
To: mace-open...@internet2.edu

Subject: Re: [OpenSAML] Testing SAML relying party browser post profile

Pantvaidya, Vishwajit wrote:
> Also I see that it is not sending any attributes in the assertion. Can I configure my profile to have it send those?
>

In Shibboleth with SAML 1, the default is to not send an attribute
statement in the SSO assertion, because in the absence of encryption
support in SAML 1, those would be in the clear and that's an undesirable
default. Instead the SP is expected to do an AttributeQuery to the
IdP's AttributeAuthority using the Subject from the SSO assertion.

[Pantvaidya, Vishwajit] I coded a simple Attribute Query request as follows. - how do I create the EndPoint object to encode my saml request?
- are their any opensaml classes that I should use for this AttrQry request-response processing interaction? If I need to use HTTPPostEncoder, I would need to include Velocity jar also. Any samples for this would help a lot.

AttributeQueryBuilder attrQueryBuilder=new AttributeQueryBuilder();
AttributeQuery attrQuery=attrQueryBuilder.buildObject();
Subject subject=assertion.getSubjectStatements().get(0).getSubject();
attrQuery.setSubject(subject);
RequestBuilder rqstBuilder=new RequestBuilder();
Request request=rqstBuilder.buildObject();
request.setQuery(attrQuery);

// Encode saml request for sending
/*
SAMLObjectBuilder endpointBuilder = (SAMLObjectBuilder)builderFactory.getBuilder(AssertionConsumerService.DEFAULT_ELEMENT_NAME);
Endpoint samlEndpoint = endpointBuilder.buildObject();
samlEndpoint.setLocation("https://idp.testshib.org");
samlEndpoint.setResponseLocation(assertion.getIssuer());
*/

HTTPPostEncoder encoder = new HTTPPostEncoder(velocityEngine,"/templates/saml1-post-binding.vm");

BasicSAMLMessageContext messageContext = new BasicSAMLMessageContext();
messageContext.setOutboundMessageTransport(new HttpServletResponseAdapter(request, false));
messageContext.setPeerEntityEndpoint(samlEndpoint);
messageContext.setOutboundSAMLMessage(request);
messageContext.setRelayState("relay");
encoder.encode(messageContext);