Wednesday, August 17, 2011

5 Minutes or Less: On SAML Audiences, Entities and Issuers

I’ve recently helped a customer who wanted to integrate a home-built SAML Identity Provider with a Weblogic Service Provider. After exchanging metadata and going through all the necessary configuration on both sides, they came across this error in Weblogic server logs:

####<Aug 15, 2011 4:55:19 PM EDT> <Debug> 
<SecurityAtn> <> <server1> <[ACTIVE] 
ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> 
<<WLS Kernel>> <> 
<1313441719095> <BEA-000000> 
- IdentityAssertionException>
####<Aug 15, 2011 4:55:19 PM EDT> 
<Debug> <SecuritySAML2Service> <> 
<bi_server1> <[ACTIVE] ExecuteThread: '0' for queue: 
'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> 
<1313441719097> <BEA-000000> <exception 
info [Security:090377]Identity Assertion Failed, 
[Security:090377]Identity Assertion Failed, 
[Security:096539]AudienceRestriction condition not satisfied (no matching 

We can clearly see that Weblogic’s Assertion Consumer Service (ACS) is trying to validate the SAML assertion. As part of that, it is verifying the AudienceRestriction condition.

According to the SAML specification, “the <AudienceRestriction> element specifies that the assertion is addressed to one or more specific audiences identified by <Audience> elements… The Audience URI MAY identify a document that describes the terms and conditions of audience membership. It MAY contain the unique identifier URI from a SAML name identifier that describes a system entity.” It also says that “the audience restriction condition evaluates to Valid if and only if the SAML relying party is a member of one or more of the audiences specified.

If you can manage to look at the actual SAML assertion being generated by the Identity Provider, you should be able to what the Identity Provider is adding as <Audience> elements. In this customer case, it was:

<saml2:Conditions NotBefore="2011-08-15T20:54:11.000Z" NotOnOrAfter="2011-08-15T20:58:11.560Z">

The ACS was actually complaining about the <Audience> value, which is wrong here.

It turns out that the Audience value must match the service provider ID. In the case of a Weblogic Service Provider, such value is the Entity ID, specified in Weblogic Console as part of the Service Provider metadata definition in the “SAML 2.0 General” tab, as in the following screen:


The Entity ID parameter uniquely identifies a partner across federation interactions.

The customer then managed to make their home-built Identity Provider adding the value of to the <Audience> element and things got all on track.

And have in mind that the URL format is only a recommendation. It can theoretically be any string less than 1024 characters long.

Another thing to be aware of is that the Assertion Consumer Service will also try to verify the <Issuer> element value in the incoming token against the “Issuer URI” in the Service Provider partner definition.


 And the “Issuer URI” value comes from the Identity Provider metadata definition that is imported into Weblogic’s Service Provider.


  1. Hi Andre,

    I have a Managed Weblogic Server configured as a Service Provider.

    Everything seems to go well, but from time to time I am getting the "Assertion is not yet valid. This cause a 403 ERROR (then if you make again the request saml2/acs/post you can access the resource).

    My server is synchronised with the ADFS and I have been setting up different values to the Assertion Time Offset and time to live, but I still have errors...

    I have implemented an AttributeMapper for feeding principals with the assertion attributes, maybe could be that the root cause of the error?

    Thanks in advance,


    1. Hi Luis, I've never seen this one, and your scenario is different than the one described in the post. I would investigate clock synch between the IdP and SP to start with. I don't think this is related to the AttributeMapper. It sounds like something related to timing.

  2. Hi,
    We are switching our single-signon provider from opensso to Weblogic's SAML 2.0. I am trying to create a test application that will send mock SAML assertions to our test Weblogic SAML server before we begin integration with the client that will send real SAML assertions.

    I have configured a Weblogic 10.3.5 instance to be a SAML Service Provider as well as created an application that creates test SAML assertions to post to the SAML server. I'm currently using a self-signed certificate to sign the SAML assertion. I've imported the self-signed cert into cacerts on the Weblogic SAML server.

    The Weblogic SAML server is giving the following error when trying to validate the signature of the assertion:

    <SAML2Assert: Digital signature does not validate with the given key
    org.opensaml.xml.validation.ValidationException: Digital signature does not validate with the given key
    at org.opensaml.xml.signature.SignatureValidator.validate(
    I get this error when the SAML assertion includes both the cert and the public key, just the cert, just the public key or neither.

    I'm pretty sure I've configured the SAML instance correctly since I followed the steps provided by another group who got this working with a different client. The only difference is they are using a real signed certificate (Verisign I believe) instead of a self signed cert.

    I'm looking for any help to track down which step in the process I've missed or implemented incorrectly.


    1. Hello, your client self-signed cert should be provided to the SP through a metadata file. This is done when you configure your IdP as an SP partner in Weblogic Console.
      Please check

    2. Sorry, I should say this is done when you configure the SP partner with the IdP metadata.


Note: Only a member of this blog may post a comment.