Java AS has a nice capability of using a custom logon module. This allows you to use alternative methods to authenticate users. A nice technical example is to use Facebook Connect as an alternative method for authentication. Check this blog for more information on how to do it on Java stack.
Unfortunately, ABAP AS does not have this capability. I hit this limitation many times before. You can have a custom HTTP handler running under service user but there is no way of switching from service user to different user. One workaround is redirecting to Java AS, perform authentication there, generate a SSO cookie and then redirect back to ABAP AS. I was still hoping for a solution that does not require Java AS. You could use same trick on ABAP AS stack if you could generate SSO cookie for any user. You can get a cookie only for current user. SAP does not provide library for generating SSO cookies. There is a library called SAPSSOEXT that gives you capability of validating SSO cookies. So you can use SAP SSO cookies in external apps for authentication.
Recipe
It's really funny that it's never occurred to me that it should not be hard to reconstruct SSO ticket structure. I knew that each cookie is digitally signed. Finally, I tried it this week and it wasn't hard at all. SAP SSO ticket has a simple structure and now when I think about it it's obvious. It's just a list of values that are digitally signed. Basically, it is composed of a ticket header and multiple pairs: field header and field value. Here is my recipe for it.
SSO Structure:
Ticket Header |
Field Header | Field Value |
Field Header | Field Value |
…… |
Field Header | Field Value |
Note that the following examples of field values are in hexadecimal format and this is not a full spec of SSO format.
The ticket header has only two fields: version and code page used for the field values.
Field Name | Length | Description |
Version | 1 byte | Always x02 (even cookie is called MYSAPSSO2) |
Code page | 4 bytes | Unicode systems seem to use code page 4102 that corresponds to UTF-16BE. It means that there will be two bytes for each character. Hence you can see value x34313032 |
The field header has two fields: field ID and length of value.
Field Name | Length | Description |
Field ID | 1 byte | - E.g. ID x01 corresponds to field username
|
Length | 2 bytes | - E.g. x0018 is a length for field username. Username in ABAP AS is 12 characters long and UTF16 has 2 bytes for each character. Hence for this field there will be 24 bytes (x18).
|
The field value is just a stream of bytes with length defined in corresponding field header. The field ID is only one byte. Therefore we can have 256 different field IDs. I've seen various field IDs. I haven't figured out meaning of all of them. Also a cookie generated by Java AS has more fields than one generated by ABAP AS. But not all fields are mandatory. Here is a list of required fields for generating a valid SSO ticket that is accepted by ABAP AS.
Field ID | Length (code page 4102) | Description |
1 | 24 bytes | Username |
2 | 6 bytes | Client of issuing system |
3 | 16 bytes | Issuing system ID |
4 | 24 bytes | UTC Creation date and time without seconds |
5 | 4 bytes | Validity in hours |
255 | Variable, length of digital signature. | Digital signature of all cookie in PKCS#7 format |
It's quite easy to generate SSO cookie in any programming language. You just need to have a crypto library that can sign binary data using PCKS#7 format.
Here is SSO cookie generation in 3 simple steps:
- Generate binary data in format described above (do not include field 255 – digital signature)
- Sign generated data with private key of certificate that is used for validating SSO tickets
- Append field 255 with value set to digital signature to binary data.
Don't forget that creation date and time must be in UTC. Otherwise it can drive you crazy when something works ½ day and it does not the other half (ratio of working/not working depends on your time zone).
I wrote my own implementation in ABAP (I told you that I wanted to have implementation without Java and using OS commands is not a nice solution). It's hosted on Code Exchange as Project Biscuit. It's a simple ABAP class but I could not find a better place for it than Code Exchange. Usage of this class is dead simple. It takes only 5 lines including variable definitions to get a valid cookie.
DATA: biscuit TYPE REF TO zcl_biscuit,
ticket TYPE string.
biscuit = zcl_biscuit=>get_biscuit( ).
ticket = biscuit->get_ticket( 'MARTIN' ).
Some final thoughts
What was my motivation to figure this out? Just recently I’ve seen a presentation about new Mozilla Persona. I really like this solution of distributed identity providers. The presenter claimed that you can include Mozilla Persona into your application in less than 4 hours. I wanted to test if it's also true for ABAP AS. I knew that I really needed to solve this authentication issue first. If anybody is wondering, yes it takes less than 4 hours to build a Mozilla Persona prototype in ABAP AS.
Why SAP does not provide a library to generate SSO cookies? I don't know. My guess is that as usual it's a mix of various reasons. Inexperienced developers can cause lots of harm by implementing custom logon procedures. You can also do lots of shady things to avoid licensing cost with this.
Final note about name: I was told that here in Australia we don't have cookies, we have biscuits. Hence the names of class, project and this blog post.
