Implications of forceAuthn/AuthnInstant

[Brent Putman]

On 10/10/13 6:48 PM, Cantor, Scott wrote:
> On 10/10/13 6:41 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:
>
>>
>> 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.
> I believe the schema allows specific RelyingParties to be associated with
> a ruleset but Brent would know better than I would.

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 at AuthnRequestsSigned.  FYI, that is what is enforced in
the default security policy with id ' shibboleth.SAML2SSOSecurityPolicy'
by the rule called ' samlsec:SAML2AuthnRequestsSigned'.

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

On the other hand, if you're maintaining a local copy of the metadata,
then you could just update it appropriately.

Otherwise, I think that, yes, you could use the "
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 '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.

HTH,
Brent


[1] https://wiki.shibboleth.net/confluence/display/SHIB2/IdPRelyingParty

[2]
http://svn.shibboleth.net/view/java-shib-common/branches/REL_1/src/main/resources/schema/shibboleth-2.0-relying-party-saml.xsd?view=markup



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131010/adb9b56f/attachment-0001.html