<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 10/10/13 6:48 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:BA63CEAE152A7742B854C678D9491383BDEE5CA0@CIO-KRC-D1MBX01.osuad.osu.edu"
type="cite">
<pre wrap="">On 10/10/13 6:41 PM, "Eric Goodman" <a class="moz-txt-link-rfc2396E" href="mailto:Eric.Goodman@ucop.edu"><Eric.Goodman@ucop.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
It appears that requiring AuthnRequest signing would be done in
relying-party.xml in the SecurityPolicy section for the relevant protocol
(e.g., shibboleth.SAML2SSOSecurityPolicy) by adding the appropriate rule
(security:MandatoryMessageAuthentication?) But those rules look fairly
global to the RelyingPartyGroup element, and not clearly scopeable to
individual RPs or ProfileConfigurations.
</pre>
</blockquote>
<pre wrap="">
I believe the schema allows specific RelyingParties to be associated with
a ruleset but Brent would know better than I would.</pre>
</blockquote>
<br>
You could do it with custom RP's, etc. However, that's not
necessarily the most direct way. If the SP indicates in its
metadata that it signs requests, then this works out-of-the box with
no additional work. They indicate this with the boolean attribute
SPSSODescriptor@AuthnRequestsSigned. FYI, that is what is enforced
in the default security policy with id '
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
shibboleth.SAML2SSOSecurityPolicy' by the rule called '
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
samlsec:SAML2AuthnRequestsSigned'.<br>
<br>
That mechanism will work as intended if the SP's metadata expresses
that, or can be made to express that. I guess a case where it might
not is if the metadata is being pulled from some central publishing
point (e.g. InCommon) and the SP doesn't want to sign AuthnRequests
to *all* IdP's and indicate such in its metadata. (I suppose one
way to circumvent that problem, if you were willing to write a
little Java, would be a MetadataFilter that took a list of
entityID's and set that flag on their metadata at runtime when its
loaded/refreshed.)<br>
<br>
On the other hand, if you're maintaining a local copy of the
metadata, then you could just update it appropriately.<br>
<br>
Otherwise, I think that, yes, you could use the "
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
security:MandatoryMessageAuthentication" rule to accomplish this, in
a more indirect manner (not enforcing signing literally, but
enforcing peer authN where the only mechanism by which that could
happen in the SSO flow would be signing). You'd just copy the
'shibboleth.SAML2SSOSecurityPolicy' security policy block, giving it
a new id and changing its content as appropriate. Then for each RP,
create a custom RelyingParty with the relevant
ProfileConfiguration(s). [1] Each ProfileConfiguration can take a
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
'securityPolicyRef' attribute which points at a specific non-default
security policy id. For some reason, we don't document this
attribute in the wiki, but you can see it in the config XML schema
[2], including what the defaults are.<br>
<br>
HTH,<br>
Brent<br>
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty">https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty</a><br>
<br>
[2]
<a class="moz-txt-link-freetext" href="http://svn.shibboleth.net/view/java-shib-common/branches/REL_1/src/main/resources/schema/shibboleth-2.0-relying-party-saml.xsd?view=markup">http://svn.shibboleth.net/view/java-shib-common/branches/REL_1/src/main/resources/schema/shibboleth-2.0-relying-party-saml.xsd?view=markup</a><br>
<br>
<br>
<br>
</body>
</html>