Shibboleth Developers

[Brent Putman <>]

On 6/3/11 12:18 PM, Bobby Lawrence wrote:
> Hi - I've been experiencing this problem lately and the only way
> around I've found is to write my own version of an IDP class file -
> not something I enjoy doing.
> I'd put in an issue/enhancement feature, but I have no way of logging
> in - I'm not affiliated with any of the organizations on the WAYF page.

Just FYI, anyone can sign up for an account at ProtectNetwork and it's free.


> Anyway -
> I have a situation where I have an SP that sends an AuthnRequest with
> an AssertionConsumerServiceURL.
> This SP has metadata so we can sign/encrypt if needed, but no ACS urls
> in the metadata as we want the IDP to use the ACS url in the
> AuthnRequest.
> However, from what I can tell from the source code, the IDP will only
> use the ACS url from the AuthnRequest if the SP is anonymous (has no
> metadata).


Yes, your interpretation is correct.  It's really a question of
security.  You want the ACS URL to be verified against trusted info from
metadata (either actually present in the metadata or at least
"authenticated").  However, the very definition of "anonymous" in the
IdP is "don't have metadata for the SP".  So using the value from the
request is the only thing you can do, and since you are already
responding to an anonymous request, the question of security is moot.


> I'm wondering if it would be a good idea to change this behavior so
> that if the SP is not anonymous and no endpoint can be found, that the
> IDP uses the endpoint defined in the AuthnRequest.


Yes, this has been brought in the past I think as a desirable feature. 
The consensus was I think that this probably makes sense to do, but
*only* if the request is signed, allowing verification that the ACS URL
is really the one intended by the (legitimate) requester (i.e. has not
been tampered with, is not someone spoofing the SP, etc)


> I dont' want to use anonymous SPs because we'd like to be able to
> sign/encrypt requests, but we don't want to hardcode ACS urls in the
> metadata.

I think that's indeed on of the very use cases that has been expressed
previously. 


> As I stated before, I can get the behavior I want my introducing my
> own
> edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler 
> class
> into the IDP with the change implemented in the "selectEndpoint"
> method, but I'd rather see this change in the IDP so I don't need my
> own version of this class.


You don't really need to modify this class.  You can just extend the
class and override that method to implement this behavior, e.g. if
super.selectEndpoint() returns null, and if AuthnRequest is signed
(assuming the use of the SecurityPolicyRule that has already validated
the signature) and contains an ACS URL, then use it.  You'd also need a
bit of Spring config tooling to plug it into the IdP, but that's not too
hard.  So you can in fact get this functionality in a supportable way
without having to modify the IdP per se, maintain forked code, etc.



> What does everyone think?
>

I can't speak for everyone, but I think in the past this functionality
was perceived as desirable.  Just has never been implemented.  Since we
aren't planning on releasing another minor version of the 2.x IdP, I'm
doubtful that this would be seen in 2.x (it's a new feature, probably
not appropriate for a patch release).  So more than likely you'd have to
wait for 3.x next year.  So implementing an extension per the above is
something to look at.

--Brent