SAML (Service Provider) without message signatures

[Angelos Varvitsiotis, geändert vor 7 Jahren.]

Hello,

(I think that this one goes to Mika Koivisto, but of course anyone else can reply, too).

We 've been trying to integrate Liferay as a SAML SP with Oracle Access Manager (v.11.1.2.3) as an IdP.
We found that (at least out-of-the-box), OAM only support signing assertions and not messages - or we
could not find how to get it to sign messages, anyway. Thus, we stumbled upon the (in)famous
SecurityPolicyException whose stack trace starts like this:

15:21:34,855 ERROR [http-bio-8080-exec-30][MandatoryAuthenticatedMessageRule:82] Inbound message issuer was not authenticated.
15:21:34,856 ERROR [http-bio-8080-exec-30][BaseSamlStrutsAction:45] com.liferay.saml.SamlException: org.opensaml.ws.security.SecurityPolicyException: Inbound message issuer was not authenticated.
com.liferay.saml.SamlException: org.opensaml.ws.security.SecurityPolicyException: Inbound message issuer was not authenticated.
	at com.liferay.saml.profile.WebSsoProfileImpl.processResponse(WebSsoProfileImpl.java:167)
	at com.liferay.saml.profile.WebSsoProfileUtil.processResponse(WebSsoProfileUtil.java:50)
	at com.liferay.saml.hook.action.AssertionConsumerServiceAction.doExecute(AssertionConsumerServiceAction.java:38)

Being unable to tune the IdP, we turned to the SP side on Liferay. Fortunately, the source code was there,
so we were able to spot this part in MetadataManagerImpl.java (circa line 418 for 6.2):

			MandatoryAuthenticatedMessageRule
				mandatoryAuthenticatedMessageRule =
					new MandatoryAuthenticatedMessageRule();

			securityPolicyRules.add(mandatoryAuthenticatedMessageRule);

By commenting out all of the above lines, we were able to convince Liferay's SP to accept the unsigned
messages from the IdP. We feel that, since the IdP sends signed assertions, this is not so terrible
from a security point of view, however we are not sure. All comments on this are welcome. Of
course, we are still actively trying to see if we can get OAM to send signed messages, but in the
meantime we ask ourselves what will happen if OAM turns out to be stubborn in this aspect and
only be able to send unsigned messages with signed assertions.

If it turns out that having only assertions signed is an acceptable security option, then it would be
nice, instead of commenting out the source code, tohave a portal-ext.properties setting control
the security policy. In fact, the code could be made to ensure that either the message signature or
the assertions signature is enforced by checking that at least one of the two properties is set to true.

How would you comment on this, Mika? Does it make sense?

Thanks very much in advance!

Angelos