Non Portal SSO2 Ticket

[frank_wagner2]

Hello,

I would like to use the SSO2 Ticket from

string ticket =SAP.Connector.SAPConnection.GetSAPSSOTicket(proxy.ConnectionString);

with the MySapSso2Ticket Class. But every ticket is refused with MYSAP_INVALID. I also tried to decode the string with Convert.ToBase64String and to my surprise it is not even a valid base64 string.

The string is also much longer than a portal ticket and contains the character '!'.

I also recieve the same ticket when I read the cookie from a BSP page on the WAS (and URL Decode it). And since connect works with the ticket, I'm sure it must be possible to convert the ticket to a valid format. I allready tried some Encoding convertion with no success.

I hope someone of you knows whats wrong.

Regards,

Frank

[Former Member]

Hello

This seems to be the same issue that I posted below but nobody could help with(subject: Invalid MySAPSSO2 cookie after portal patch - bad Base64).

This started happening with a recent portal service pack (seems to be SPS11 and later).

I've tried removing the ! completely and sometimes that works. Sometimes I need to add more = characters at the end to make it a valid Base64 string.

Unfortunately, a permanent solution or even an explanation seems elusive...

Regards,

Szeming

[Former Member]

We are trying to connect to a SAP BI system using SAP .Net Connector.

We were able to establish the connection and using the function GetSAPSSOTicket we were able to retrive the token as base 64 string.

Does anyone know how to convert this as a cookie object and store it in session?

Any help on this would be greatly appreciated.

Regards,

Sumit

[reiner_hille-doering]

Can you please post some samples of the different tickets?

Have you checked that both Portal and WAS use the same (secret) PSE file? Does WAS allow connects with the ticket from portal?

[frank_wagner2]

Hu, you are fast...

> Have you checked that both Portal and WAS use the

> same (secret) PSE file? Does WAS allow connects with

> the ticket from portal?

There is no portal involved. The application is a .NET Forms application connecting to a Web Application Server. I created the verify.pse from transaction STRUST (System-PSE).

> Can you please post some samples of the different

> tickets?

A sample ticket (wrapped):

AjQxMDMBABhGAFcAQQBHAE4ARQBSACAAIAAgACAAIAACAAYwADAAMQADA

BBTAE8ATAAgACAAIAAgACAABAAYMgAwADAANgAwADIAMAA2ADAAOQAxAD

EABQAEAAAAPAYAAlgACQACRAAKAAxGV0FHTkVSICAgICALAANTT0wMAAh

TT0wgICAgIA0ADDIwMDYwMjA2MDkxMQ4AAP8ChDCCAoAGCSqGSIb3DQEH

AqCCAnEwggJtAgEBMQswCQYFKw4DAhoFADALBgkqhkiG9w0BBwGgggGJM

IIBhTCCAUMCAQAwCQYHKoZIzjgEAzAOMQwwCgYDVQQDEwNTT0wwHhcNOT

cxMDAxMDAwMDAwWhcNMzgwMTAxMDAwMDAwWjAOMQwwCgYDVQQDEwNTT0w

wgfIwgakGByqGSM44BAEwgZ0CQQD//VXmPsVP7pqcket6h5KWtnyiSuo8

pfFvGzzZZpqk3N6foYAzlg4K4gVHYyt7dd2UxfVb1s2O1JORO844eCxrA

hUA5cyFRWe34AOh2d3/jXOwIQ3xWi8CQQDvFfVvNHAiiBUoTXGdI!

nBzmGnDGIGMXXL54FC!rXXMe4bGHRkPrmLUk6M4tUBNenX9gG8qAn/m3Ibg8x6kGAA0QAAkEAh/d

lRBU7Iz6/l4i28OkjTUXD8Gf5dbk8keTaqcqB3rJbCSlCRaZsohxN/r40

s4dmQHjUpqyFtBvKBE55wvEgqzAJBgcqhkjOOAQDAzEAMC4CFQCSBa0s0

JPk6muNk1I0rhrfADrqQIVAI4TlJVS6RRxp0bho95tczPDLCVpMYHAMIG

9AgEBMBMwDjEMMAoGA

1UEAxMDU09MAgEAMAkGBSsOAwIaBQCgXTAYBgkqhkiG9w0BCQMxCwYJKo

ZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAyMDYwOTExNTdaMCMGCSq

GSIb3DQEJBDEWBBROQNH!aK1h/jJyaIU6C7FIEGMnzzAJBgcqhkjOOAQDBC4wLAIUIcnTSh0eg3ljD

Ap40Sdwm6ki6HMCFH2vv6tYrGhuCC6!p9PEF70oI4w0

Regards,

Frank

[reiner_hille-doering]

> Hu, you are fast...

Not allways...

> There is no portal involved. The application is a

> .NET Forms application connecting to a Web

> Application Server. I created the verify.pse from

> transaction STRUST (System-PSE).

If no portal in involved, the returned ticket works for SSO and is the same as from BSPs, why do you want to use the Ticket Toolkit on it?

I would also expect that it should work - at least you have all the required DLLs in the correct versions - but if not, you should be able to create a workarround, e.g. keep the username in a second cookie.

BTW: I assume that you passed "2" as the second parameter of GetSAPSSOTicket()? Else you may get a MYSAPSSO1 ticket.

[frank_wagner2]

> If no portal in involved, the returned ticket works

> for SSO and is the same as from BSPs, why do you want

> to use the Ticket Toolkit on it?

Because it should allow a smart way to determine how long the ticket will be valid.

The general idee:

The application starts a bsp app in integrated Internet Explorer. This page contains some information and gui interfaces what would be hard to create in .NET Forms (e.g. for reporting). Here the user is also authenticated by bsp.

To not force the user to enter also Username/password for the .NET part I tried to use sso2 cookie. But this will expire after some time. So the idee was, to refresh the Ticket before it expires.

And at this point I noticed that something is wrong with the ticket.

During the day I also tried what happens when I replace the character ! with +.

proxy.Connection.Open();

ticket = SAP.Connector.SAPConnection.GetSAPSSOTicket(proxy.ConnectionString, 2);
            proxy.Connection.Close();
                       
            ticket = ticket.Replace("!", "+");
            byte[] bytes = Convert.FromBase64String(ticket);

Now the code passed Convert.FromBase64String without Exception. And MySapSso2Ticket also accepts the ticket, but returns only the username and it is not valid.

I also tried to reuse this modified ticket for a new authentication. As expected, it fails.

I would understand if the ticket is somehow corrupted on the way from browser to client. Ok, but what surprises me is that GetSAPSSOTicket returns the same ticket, also with the non Base64 characters in it.

> BTW: I assume that you passed "2" as the second

> parameter of GetSAPSSOTicket()? Else you may get a

> MYSAPSSO1 ticket.

Yes, i had not copied the coding

[reiner_hille-doering]

Ah, I get the point.

I could immagine that different versions of the ticket creation and check library used on your server and in the Ticket Toolkit. The Toolkit used wpsso_v3.dll, version 7.0.0.0 and some sapsecu.dll version. You could search your application server for similar DLLs with different version.

You could also post the question to some other forum (ABAP / WAS?), because I don't think that my .NET wrapping causes the problem, but the underlying unmanaged DLL.

[Former Member]

Hello,

I don't think the problems could be explained by a version problem. There are 3 points that confuse me:

- why is the ticket string returned by WAS much longer than a ticket from the portal?

- why does it contain invalid characters for a base64 string?

- why does the .net connector accept this invalid base64 string for connect?

From your last post I suggest that you directly involved in the development of the .net connector wrapper. I'm wondering if you perform some convertion on the ticket string before you call the unmanaged part? If yes, this would perhaps help me to handle the ticket.

Regards,

Frank

[reiner_hille-doering]

The .NET Connector doesn't process the ticket, but simply gets it from LIBRFC32 function (which gets it over RFC protocoll from backend). Passing it in is just addding it to the connection string.

Also the Ticket Toolkit simply passes the string to a DLL function; there is no conversion in the middle.

It's also strange to me that the ticket is not a valid base64 string - on the other hand nobody defined that it should be one - it is simply defined to be a string.

In the meantime I also found an OSS note (612670) that mentions that Mysapsso2 tickets created by WAS could have limited features compared to the ticket created by the portal.