Layer7 API Management

Hi,

I Have an incoming request (non SOAP) message which contains a base64 encoded SAML Response Assertion.

I have decoded the base64 and stored the SAMLResponse element into  a context variable.

I successfully verify the SAMLResponse signature using assertions :" (Non-SOAP) Verify XML Element" and "(Non-SOAP) Check Results from XML Verification".

Verify XML Element is using prefix m_saml_signature to store signature validation results.

Having put some audit logs, I can see the values of signature validation: m_saml_signature.signingCertificates and m_saml_signature.signingCertificates.1.serial

Then I try to use the validated signature certificate as credentials for authentication so I use assertion: "Retrieve credentials from context variable Assertion" with context variable input value : m_saml_signature.signingCertificates.1

It always failed with the following log message:

Here is the Policy abstract :

Anyone can help ?

Thanks.

Hi Nicolas,

Do you see a stack trace at all in the log file at: /opt/SecureSpan/Gateway/node/default/var/logs/ssg_0_0.log ?  Usually an internal server error results in an exception & stack trace which may help.

Cheers,

Julian

Hi Julian,

Thanks for your suggestion, but unfortunately when the problem occurs, only logs in ssg_0_0.log are:

...

[

  Version: V3

  Subject: CN=ACME-ADP-2014, OU=ipc, O=adp, L=toulouse, ST=haute-garonne, C=fr

  Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5

  Key:  Sun RSA public key, 2048 bits

  modulus: 23865930763485494815617651932829398347051618593988819909990194091632329094137304288704626933281800609584502623600451508044033880132965285860057587588051478545602064085687393220943878887622200542454989107166796430200811249926824349421009269339661754127601393249667088867353064699329172894776571860311231413405910142739346437543085996686166221129672666499938057791728610135125720529620925127361813853259945170649667952925575025437628865423278572800178979569823257345071281650886311137850411694669257997962648346340553665049860334687238547539259657085048822086371280691172615023752116518875399933346068379198797496278587

  public exponent: 65537

  Validity: [From: Wed Mar 26 17:06:39 CET 2014,

  Issuer: CN=ACME-ADP-2014, OU=ipc, O=adp, L=toulouse, ST=haute-garonne, C=fr

Certificate Extensions: 4

[1]: ObjectId: 2.5.29.35 Criticality=false

AuthorityKeyIdentifier [

KeyIdentifier [

0000: DC 45 04 C7 92 25 40 16   D7 8A 9F 78 BA DA E3 B2  .E...%@....x....

]

[CN=ACME-ADP-2014, OU=ipc, O=adp, L=toulouse, ST=haute-garonne, C=fr]

]

[2]: ObjectId: 2.5.29.19 Criticality=false

BasicConstraints:[

  CA:true

  PathLen:2147483647

]

[3]: ObjectId: 2.5.29.15 Criticality=false

KeyUsage [

  DigitalSignature

  Key_Encipherment

  Data_Encipherment

  Key_Agreement

  Key_CertSign

]

[4]: ObjectId: 2.5.29.14 Criticality=false

SubjectKeyIdentifier [

KeyIdentifier [

0000: DC 45 04 C7 92 25 40 16   D7 8A 9F 78 BA DA E3 B2  .E...%@....x....

]

]

]

  Algorithm: [SHA1withRSA]

  Signature:

0000: B2 62 74 15 B6 57 04 9D   D7 97 12 63 61 1B 50 46  .bt..W.....ca.PF

0010: B2 DF D9 E5 3D 17 9D 7E   DB 10 F6 5E F0 4A 35 B1  ....=......^.J5.

0020: 3B 3E 6C 78 5B 74 07 88   D4 30 28 5F 00 2F 66 82  ;>lx[t...0(_./f.

0030: D8 33 77 11 AA 4C DB 5B   D4 9E 63 1E D0 28 98 40  .3w..L.[..c..(.@

0040: D3 A4 7C BE 3D CD 81 62   B1 CB 73 E3 70 35 A6 C8  ....=..b..s.p5..

0050: 6A C9 AB C6 B8 9F 50 34   70 39 A3 47 7C F9 04 3A  j.....P4p9.G...:

0060: BD BB D6 36 05 FD 03 49   44 B1 9E 0F E5 EE D1 45  ...6...ID......E

0070: 47 D6 17 E6 B1 22 5A AB   4A 49 5A 71 CB C8 B0 CD  G...."Z.JIZq....

0080: 8C 98 B5 36 6F 8F 15 DC   3F 71 B4 45 A5 F7 F4 1B  ...6o...?q.E....

0090: 39 B0 5F 85 FF AE D2 F2   EC 84 BA 8C E2 48 B1 38  9._..........H.8

00A0: A2 6C 05 FF 98 93 26 2D   11 57 34 AB AE 1C D1 9A  .l....&-.W4.....

00B0: 09 9B 77 8D 8A 4D 3C 68   D0 88 3E CC 40 16 09 3C  ..w..M<h..>.@..<

00C0: 16 D4 01 2A D5 0E AA 55   E7 58 60 ED 47 13 1B 0E  ...*...U.X`.G...

00D0: F7 FD C9 E2 1C 0D F5 5F   0B 8D 6D 8B 06 BD 6D A6  ......._..m...m.

00E0: FC D9 DC AE 8C FB 06 DF   0D DD A6 82 03 B7 C6 30  ...............0

00F0: 15 7B 52 45 04 71 22 C5   6A 60 38 73 B5 41 E0 B4  ..RE.q".j`8s.A..

]

2015-09-30T08:35:14.257+0200 WARNING 343 com.l7tech.server.policy.assertion.ServerAuditDetailAssertion: 151: Variable 'm_saml_signature.signingCertificates' is not a String and cannot be converted to one.  (Actual type: sun.security.x509.X509CertImpl)

2015-09-30T08:35:14.257+0200 WARNING 343 com.l7tech.server.message: Message was not processed: Internal Server Error (500)

So basically, nothing more than what you get in the Audit tools ...

Hi Nicolas,

You can "turn up" logging by doing this:

• set the cluster-wide property "log.levels" to 'com.l7tech.level = FINEST'
• change the Severity Threshold for the Gateway log to FINEST

This will increase the amount of info in your log massively so I suggest tailing the log at the command line, running your test then stopping the tail command quickly otherwise the relevant entries will scroll past too quickly.  This may allow you to see more details, including the stack trace regarding your issue.

Cheers,

Julian

Hi Nicolas,

A solution could be to authenticate a virtual group or a group against a Federated Identity Provider (FIP) instead of the "Retrieve credentials from context variable" assertion.

If you need any information from the certificate, you could use the "Extract attributes from Certificate" assertion" after that.

If you need any help, let me know.

Cheers, Heiko Hudig.

Hi,

I have found a working solution to my issue.

In fact it seams that you can't use directly the result of the "(Non-SOAP) Verify XML Element //ds:Signature as a certificate type context variable for the "Retrieve Credentials from context variable".

You have to go through an intermediate assertion : "Look up certificate".

So finally I have a dedicated "Identity provider" which is in fact an "LDAP based certificate store" and which contains all the "acceptable certificates".

I validate the SAML Response or SAML Assertion signature.

Then I look up for a certificate based on Signature Validation Result Certificate issuer and serial.

Then I validate certificate (validity date).

Then I Retrieve credentials from my "valid" certificate.

And Finally I Authenticate against my IDentityProvider (LDAP Cert store).

Here is the Policy Abstract: