Is there a Apigee Java Callout for SAML Encryption/Decryption ?

Looking for a solution for SAML Encryption & Decryption in Apigee API Flow which can,

  • Encrypt SAML Assertions
  • Decrypt SAML Assertions
  • Validates SAML Assertion attributes (Issuer, Entity, etc.)
  • Populates custom SAML attributes as Apigee variables for access in subsequent policies

~~ Q : Source : Slack ~~

Solved Solved
1 18 944
1 ACCEPTED SOLUTION

Former Community Member
Not applicable
18 REPLIES 18

Former Community Member
Not applicable

Sure. Here is a sample implementation: https://github.com/srinandan/apigee-saml-callout

Thank you @Srinandan Sridhar for sharing sample proxy with community.

@srinandans@google

Does your code support to create SAML auth-request ?

Hi srinandans@google

The implementation is really helpful, there is a requirement to encrypt some field of the assertion after digital signature of assertion. can you guide on this step.

Regards,

Ishan Tandon

Can you be more specific, please. Exactly which fields? Give an example.

Hi srinandans@google @Dino I cloned above repository locally to use it for decrypting SAML assertion, it was all good until we deploy proxy to production. on non prod environment we didn't have any issue but on production if this Java callout policy fails because of validation error(i.e. invalid private key or corrupted SAML) then it creates ESAPI configuration issue.

We got reply from Apigee support as below

DefaultBootstrap.bootstrap()

Default.Bootstrap() re-initializes the OpenSAML libraries, including the ESAPI libraries. However, it doesn't initialize the ESAPI libraries the same way Apigee initializes them, which is causing the ESAPI issue. Please create a custom Bootstrap call to just initialize the XML parser and not initialize any of the libraries that were already initialized by Apigee.

Can someone help please?

Thanks

Hi Harmeet,

Can you please try to put the

DefaultBootstrap.bootstrap() inside the execute method instead of static block, This will resolve ESAPI validation issue

Regards,

Ishan Tandon


.

Thanks @Ishan ,

Quick question have you faced this issue in past?

Not sure why it causing issue only in prod environment when we are running same version of Apigee and proxy code in prod and non prod.

Asking because I have to be extra careful because I have to bring down services to test this on prod as I can't re produce this on test envs.

Thanks

Harmeet

Hi Harmeet,

Is it possible for you to share the error you are facing, I was facing the ESAPI validation issue in non prod, but the resolution that i provided worked for us, promotion to higher env is aligned in upcoming weeks, so as of now no experience with this code in prod env.

Hi Ishan,

I am getting blow error

The selected type [EnvironmentName] was not set via the ESAPI validation configuration

We are using private cloud version of Apigee and on non prod instance we didn't get this error at all. only production instance(completely separate physical instance) we are getting this error.

Thanks

Harmeet

Hi Harmeet,

I faced the same error and now with the changes that I mentioned above i.e

"try to put the DefaultBootstrap.bootstrap() inside the execute method instead of static block" the error got resolved.

Is there any difference in non-prod and prod env, any version diff

Regards,

Ishan Tandon

Thanks Ishan,

I have made suggested changes but didn't test yet as I am facing issue on prod only so we need bit of planning.

We have exact same version of OPDK on prod and not-prod, hence it's confusing what's going on.

Thanks for your help and confirming it. Will let you know if solution works.

Regards

Harmeet

Hi Ishan,

I tried above solution and it's same result. works fine in not-prod and in prod is causing ESAPI error.

Thanks for your help and suggestion.

Regards

Harmeet

Hi Harmeet,

Are you able to resolve the issue?


Regards,

Ishan Tandon

@Harmeet Singh Sra

Hello Harmeet,

I am facing also ESAPI error. can you please suggest which solution worked for you in production.


Thanks and Regards

Uday

Did you try this?

Default.Bootstrap() re-initializes the OpenSAML libraries, including the ESAPI libraries. However, it doesn't initialize the ESAPI libraries the same way Apigee initializes them, which is causing the ESAPI issue. Please create a custom Bootstrap call to just initialize the XML parser and not initialize any of the libraries that were already initialized by Apigee.

@Uday, none of these resolved my issue. As this was prod so we couldn't hit and try to test various suggestions suggested by Apigee support. For time being we have disabled encryption.

Also we will try to create new org and env in prod cluster and try it there.

To be honest Apigee should support encrypted SAML assertion validation in the policy itself.

@Dino we never got clear answer from Apigee what exactly we should remove from bootstrap function.

Once I have new org then will try again and update here.

Thanks

Harmeet

we never got clear answer from Apigee what exactly we should remove from bootstrap function.

Yes, I agree with that. "Please create a custom Bootstrap call to just initialize the XML parser and not initialize any of the libraries that were already initialized by Apigee." is not specific enough. It could be more helpful.

Unfortunately I don't know the specifics enough to guide you further. If I were doing the work, I'd look in the DefaultBootstrap source, and in the stacktrace generated when my callout invokes DefaultBootstrap.bootstrap(). Then, triangulating from those two bits of information, I'd try to figure out which of the things I need to initialize, and which ones I can lave out.

Keep in mind you will need to keep the full initialization in the test source; doing testing outside of the Apigee MP will require that you initialize everything.

Once I have new org then will try again and update here.

Thumbs up.