Error while creating assertion ticket on demand

[Former Member]

Hi,

In my CE system, the defaulttrace file is giving the following errors every 1 minutes and I am not sure how this has started happening all of a sudden:

Error com.sap.engine.services.security.authentication.loginmodule.ticket#

BC-JAS-SEC#security#D2823D79CD020028000002290008003A#103882950000002534##com.sap.engine.services.security.authentication.loginmodule.ticket####1F1699B0AC2011DFA650D2823D79CD02#1f1699b0ac2011dfa650d2823d79cd02#1f1699b0ac2011dfa650d2823d79cd02#0#System [20]#Plain##

Error while creating assertion ticket on demand. Current principal is null.#

Also,

--An error occurred while trying to generate an SAP authentication assertion ticket

--Assertion ticket could not be retrieved. Error was null.

Any idea why this is happening and how can I solve this?

As a background I can also mention that we are using a RFC destination SAP_ECC from the java stack to backend ECC and the login method has been set to "Current User (Assertion Ticket)". SSO settings were already completed and the SSO was also working fine. Also, if I change this option to Logon Ticket, the error disappears but changing it back to assertion ticket brings it on again. Obviously, since this is system to system integration, I cannot use logon tickets and assertion tickets are definitely the right choice.

Thanks,

Shitij

[Former Member]

Is this issue resolved? Even I can see on our CE system after recent patching.

Thanks,

S

[JaySchwendemann]

I get this error on a PI 7.4 AEX while using an http sender channel and having 3 J2EE nodes on the server. In channel monitoring --> ping channel 1 server nodes get through and the other two get an error.

Anybody had this behavior? Any further clues on how to maybe deactivate principal propagation?

Cheers

Jens

[manjunath_b]

Hello Jens,

Did this issue get resolved? What was done?

Regards,

Manju

[JaySchwendemann]

Hi Manjunath,

we had an incident raised at SAP and they told us we don't have a supported configuration for authentication and single sign-on. Specifically we used policies "evaluate_assertion_ticket" and "ticket" both from the template. It seems only either of them was supported.

Please check in nwa --> configuration --> security --> authentication and single sign-on --> authentication and resolve using e.g. the help file Login Modules - User Authentication and Single Sign-On - SAP Library

HTH

Cheers

Jens

[former_member184154]

Hi Jens,

I'm probably facing the exact same issue (Assertion ticket could not be retrieved. Error was null)

My scenario is PO 7.4 (java stack only) -> SSO -> ECC 6.07 --- (SOAP to RFC)

I read with interest your suggestion about what SAP OSS told you, but could you elaborate a bit further about this?

I'm confused now about whether "evaluate_assertion_ticket" OR "ticket" should be used...

In my case, the Java AS must issue an assertion ticket, not evaluate it, so I would keep "ticket" and get rid of "evaluate_assertion_ticket". Am I right? How to do it?

Any suggestion would be greatly appreciated.

Thanks for your time.

Warm regards,

Alex

[JaySchwendemann]

Hi Alex,

actually we didn't solve this as we had another issue that we thought had to do with multiple server nodes. Therefor we downgraded our system from 3 server nodes to 1 server node, hence effectively eleminating the "problem".

As we never actively tackled the problem, I'm actually not that sure if the proposed solution from SAP does indeed eleminate the problem.

That being said I think the helpfiles about that topic are a bit contradictory:

1. Using Logon Tickets with AS Java - User Authentication and Single Sign-On - SAP Library

--> says that assertion tickets use login modules "CreateAssertionTicketLoginModule" and "EvaluateAssertionTicketLoginModule". The corresponding template was "evaluate_assertion_ticket"

2. Configuring a Trust Relationship for SAP Assertion Tickets - Configuring Process Integration After I...

--> tells you that in your special case, Alex, you are in the variant "AS Java: Client Side". You should "select" the login module "CreateAssertionTicketLoginModule" and add an option "ume.configuration.active" with value "true". It does not say that you should change any template at all

3. Configuring the AS Java to Issue Logon Tickets - User Authentication and Single Sign-On - SAP Librar...

--> states that "ticket" is the template for logon tickets, which are similar but not the same as assertion tickets, hence should not be of direct interest to your scenario

4. Configuring the Sender - Configuring Process Integration After Installation - SAP Library

--> says that the SOAP client must be able to issue SAP assertion tickets. This would be feasible if your sender is a SAP system. In that case you have a SOAP (XI) Sender or a HTTP Type G destination. If not a SAP sender system, it seems you are going to have problems, apparently.

See here for a quote of on SOAP Sender. http://scn.sap.com/community/pi-and-soa-middleware/blog/2007/01/16/principal-propagation-in-sap-xi#c... not sure though, if this limitation still applies

Conclusion:

I would check if your SOAP sender could really issue an assertion ticket.

If yes, end-to-end PP should be possible.

If not, one COULD assume that PP from PO --> ECC MIGHT stilly be possible reading this helpfile Configuring Principal Propagation Using the Advanced Adapter Engine - SAP Process Integration - SAP ... where in paragraph "Recommendation" SAP says, that checking one box (half way PP) should be possible. In that case I would assume that you need to configure your PO to just issue assertion tickets - Login Module = CreateAssertionTicketLoginModule - and get rid of the evaluating module "EvaluateAssertionTicketLoginModule". Taking a long shot here, though.

HTH

Cheers

Jens

[former_member184154]

Hi Jens,

Thank you so much for the time you spent on this reply. It was really helpful to me.

In fact, I was so close... At the end, tracing Security at level 2 with SM50 showed me the problem, very stupid: for testing purposes, I had changed on the fly the client (mandt) to which my Rfc rcv channel was connecting to, so that client was not trusted by PO

Once I fixed that, SSO worked like a breeze.

I simply use a basic ping SOAP operation (no input) mapped against Rfc USER_NAME_GET (no input) which gives you back the currently logged on user's details.

By the way I am invoking the WS with SoapUI and actually performing a simple basic auth (so no assertion ticket at the beginning): the user I provide in SoapUI is a PO local UME user and also exists in ECC (SU01). Flagging "Principal Propagation" both in Inbound and Outbound processing in my IC makes the magic!

Many thanks again

Alex

[JaySchwendemann]

Great to hear that it's working now.

Also nice to know that one can use a scenario like this:

Generic Soap Sender (Basic Auth) --> (Principal Propagation) --> PI --> (Principal Propagation) --> SAP AS ABAP (RFC)

(I hope I got your scenario correctly)

Cheers

Jens

[former_member184154]

Jens,

Yeah, you got it right!

And we also did something better just few minutes ago by enabling HeaderVariableLoginModule on the SOAP Adapter, and it works, too!

Thanks a lot

Alex