Reg Re-authentication for Tcode access

[Former Member]

Dear All,

I want to enable Re-authentication for certain tcode access in my SAP ABAP system. The SAP as such supports this with the SSF settings. I have the SSF working but am not sure how to enable the particular tcode for Re-authentication.For example i have created a z code zAl08 out of Al08 for test purpose.When an user tries to access zAL08 he should be asked to give his credentials for authentication and then should be able to access the tcode.

1.Is this possible. (am already using a Security product working properly in my environment)

2.How to configure(Steps) the zcode for enabling Re-authentication?

Regards,

Karthik

[Former Member]

If you want to re-authenticate using an ABAP password, you can do this with function module SSFT_PPPI_SIGN.

But you also said:

> (am already using a Security product working properly in my environment)

If you want to re-use that security product, you will probably have difficulties.

Cheers,

Julius

[tim_alsop]

Karthik,

To confirm my understanding of your request. Are you using SNC for Single SignOn, and you want to specify some transactions so that when user runs the t-code they are asked to re-authenticate before the transaction is started ? Is this correct ?

Thanks,

Tim

[Former Member]

Hi Tim,

Exactly.i have SSF and also have SNC been setup on my SAP Server.I just want to use this setup for Re-authentication for certain TCODE access.So i needed the procedure to set up the tcodes for Re-authentication in SAP server.Once this is setup i know the procedure to use the third party security libraries for testing this setup.

Regards,

Karthik

[tim_alsop]

Karthik,

There are two implementations of SSF - one involves using certificates stored in ABAP database, and the other involves client software installed on workstation where SAP GUI is installed. This software will authenticate using a client certificate (e.g. form smart card). I assume you are using the server side SSF.

The vendor of the SNC software should be able to provide you with what you need, since SNC is handling user authentication via an external authentication server (e.g. Active Directory). You would therefore need the same authentication method to re-authenticate the user when a t-code is executed. I represent one of the SAP partners who provide an SNC solution to SAP customers, and I know we can make the changes to support your requirements if needed. We would likely use the exit available in ABAP which is invoked whenever a t-code is run - this exit would use our client software to show a signon screen to use and they would be able to enter an Active Directory password for the account they are logged onto at workstation. I think this might be what you are looking for ?

Thanks,

Tim

[Former Member]

> ... the exit available in ABAP which is invoked whenever a t-code is run.

There is to my knowledge no such thing - an exit in the standard S_TCODE check. I also cannot imagine there being one ever as it is a kernel side check and not (only) checked in ABAP.

You would need to find an apppropriate exit or enhancement point to be able to use the transaction each time, for each transaction. They will differ each time.

Creating a Z-transaction ZEXAMPLE to simply call EXAMPLE won't be reliable either, as the user could possibly start EXAMPLE directly or run it as a report or call it from a related transaction's menu.

If you create the ZEXAMPLE from scratch to replace EXAMPLE or copy all the code over and not just the tcode, then it might work.

But then you might as well simply modify the function module...

Cheers,

Julius

[tim_alsop]

>

> There is to my knowledge no such thing - an exit in the standard S_TCODE check. I also cannot imagine there being one ever as it is a kernel side check and not (only) checked in ABAP.

It seems you are not 100% sure on this - how can we confirm ? The reason for my doubt is that I am aware of a product froma vendor which does something similar to what I have described. It allows the admin to configure which t-codes are required and whenever that t-code is launched the user is re-authenticated. I am sure this vendor didn't change all t-codes to make this occur on entry ... My understnading is that there is an exit for logon to ABAP and one for whenever a t-code is run.

Thanks,

Tim

[Former Member]

>

I am sure this vendor didn't change all t-codes to make this occur on entry ... My understnading is that there is an exit for logon to ABAP and one for whenever a t-code is run.

Hi Tim.

If we are thinking about the same vendor, then each transaction which requires the additional authentication needs to be modified in some way. At least, that is what I was told when I spoke to them a while back. I like the product but that part of the technology for me is the part which requires a company to really want it to consider implementing it.

[Former Member]

It would have to by in the code somewhere (presumably right upfront) but cannot imagine that it is invoked by the start of the transaction itself.

You can see how this check is performed by looking at function module AUTH_CHECK_TCODE which C-calls the kernel function by the same name. The only option at the application layer is to control "couples" of transactions which trust each other in called : calling relationships to bypass the S_TCODE check.

I cannot see anyway to add your own code to this without modifying the kernel - and I cannot see that happening either.

If you and Alex are thinking of the same vendor as I am with the biometric checks, then as far as I know these checks are used when performing certain tasks after having started the transaction. For example, when approving a purchase requisition which exceeds a certain amount.

For this you would need to find the appropriate exits and enhancement points, just like everyone else does, and add the code each time in the best available location.

BTW, a cool website to use for this is www.abapninja.org. I would also recommend using enhancement points and not customer-exits or modifications, and then make use of the switch framework to activate and deactivate them for trouble-shooting, patching and upgrades.

> My understnading is that there is an exit for logon to ABAP and one for whenever a t-code is run.

I will forward this to 2 gurus who would know for sure. If there is an exit in the S_TCODE check then I will eat my hat...

Cheers,

Julius

[Former Member]

>

> For this you would need to find the appropriate exits and enhancement points, just like everyone else does, and add the code each time in the best available location. 

Exactly, then we have upgrade considerations & copies of standard transactions where there are no suitable exits or enhancement points.

>

> I will forward this to 2 gurus who would know for sure. If there is an exit in the S_TCODE check then I will eat my hat... 

I really hope there is an undocumented feature somewhere which allows this

[Former Member]

Dear Tim,

Am using a Client side authentication using digital certificates, which holds the certificates and to use them for enabling SSF and for Critical TCode reauthentication.

Regards,

Karthik

[WolfgangJanzen]

>

> My understnading is that there is an exit for logon to ABAP and 
> one for whenever a t-code is run. 

Well, there is a customer-exit which is executed AFTER a successful SAPGUI logon took place (notice the capitalized words).

But I'm not aware of any customer-exit / BADI / ... for transaction starts.

Regards, Wolfgang

[tim_alsop]

Hi,

I will ask the vendor who has the product I mentioned earlier to explain how they have implemented their product such that a user can be re-authenticated for any transaction. I know I was told it was done via an exit, but it was a senior person who was/is not that technically minded who told me that so he might have also missunderstood. I know a consultant who works for the company who will know for sure how this works - I will report back when I have a response.

Karthik,

If you have a client side SSF library and are using client certificates, then the SSF library would need to be invoked somehow when a transaction is started and the client software would then need to reauthenticate the user.

Thanks,

Tim

[Former Member]

>> If there is an exit in the S_TCODE check then I will eat my hat...

>

> I really hope there is an undocumented feature somewhere which allows this

Come on Tim and Alex! Match my hat and raise it by a pair of shorts.

Cheers,

Julius

[Former Member]

> ... then the SSF library would need to be invoked somehow when a transaction is started and the client software would then need to reauthenticate the user.

I seem to have missed the small print here...

Maybe you are thinking of adding code to the client side SNC library which requests re-authentication when the user attempts to start a transaction from the ok-code field or a menu object, before the request to start the transaction is sent to the application server.

I cannot see this working, as what happens when the user calls the transaction from another transaction's menu or a shortcut or starting the SAPGui from a command prompt and logging on with a password, or an ABAP RFC function runs the same functionality, or a webservice for it is exposed? In these cases the S_TCODE check might still be there and in others it is intentionally not checked as it does not make sense -> it is invoked from the ABAP program on the application server and not the SAPGui on the client side.

Some folks might also be tempted into trying GUI scripting to achieve this. That is notoriously buggy and cumbersome and to my knowledge has reached the end date of it's shelf-life so few customers would go for that option.

I can't see this working in any reliable way by adding custom code to some central point or distributing it to the client side.

S_TCODE only provides a very general layer of security and can be re-used for coupling transaction pairs when the initialization of their programs warrant this. Most critical transactions are protected in their source anyway and donu2019t care whether you are running it from SE38 or MIGO...

Cheers,

Julius

[tim_alsop]

Julius,

I am not clear on your last post - it confuses me

Anyway, I talked with the vendor who has a solution that offers re-authentication when a transaction is started. They told me they cannot give me any details on how they do this because it is confidential information. This surprises me because any company or person serious about security and wanting to evaluate their product would need to know how it works.

So, without any clear way to run security code (which would re-authenticate the user) when a transaction is executed by a user there doesn't appear to be a solution to this problem available today. Maybe one day SAP will improve their product and provide a clear and secure interface to allow vendors/customers to develop this functionality.

Thanks,

Tim

[Former Member]

Basically, what I said was:

.

function auth_check_tcode.

*"----

-

---

""Lokale Schnittstelle:

*" IMPORTING

*" VALUE(TCODE) LIKE TSTC-TCODE

*" EXCEPTIONS

*" PARAMETER_ERROR

*" TRANSACTION_NOT_FOUND

*" TRANSACTION_LOCKED

*" TRANSACTION_IS_MENU

*" MENU_VIA_PARAMETER_TRANSACTION

*" NOT_AUTHORIZED

*"----

-

---

• Dieser Funktionsbaustein dient als reine Kapsel für den C-Call

• auth_check_tcode und ist daher im Gegensatz zu authority_check_tcode

• nicht für die Prüfung vor dem Call Transaction gedacht, sondern für

• die Fälle, in denen ein Start Transaction geprüft werden soll,

• z.B. in der SE93.

• authority_check_tcode berücksichtigt wie der Kernel die per SE97

• pflegbaren Einträge in der Tabelle tcdcouples.

• Berechtigungsprüfung

call 'AUTH_CHECK_TCODE'

id 'TCODE' field tcode.

if sy-subrc = 0.

• auth_check_tcode enthält die Prüfungen von tcode_executable,

• daher im OK-Fall keine Aufruf nötig.

else.

perform tcode_executable using tcode.

• Keine Berechtigung für Transaktion &

message i077(s#) with tcode raising not_authorized.

endif.

endfunction.

*----

---

*

• FORM tcode_executable *

*----

---

*

• ........ *

*----

---

*

• --> TCODE *

*----

---

*

form tcode_executable using tcode.

call 'DY_CHECK_TRANSACTION'

id 'TX' field tcode.

case sy-subrc.

when 0. " Alles ok, return

when 1. " Parameter Error

message i274(00) raising parameter_error.

when 2. " Transaktion nicht gefunden

message i343(s#) with tcode raising transaction_not_found.

when 3. " Transaktion gesperrt

message i348(s#) with tcode raising transaction_locked.

when 4. " Transaktion ist Bereichsmenü

message i037(oz) with tcode raising transaction_is_menu.

when 5. " Bereichsmenü via Parameter-Transaktion

message i350(s#) with tcode

raising menu_via_parameter_transaction.

when 6. " Nicht berechtigt; vorgesehen, aber nicht implementiert

message i077(s#) with tcode raising not_authorized.

endcase.

endform. "tcode_executable

</pre>

.

Sorry, the comments are in German. But as you can see, there is no exit and the checks are in the kernel only.

My hat is safe...

Cheers,

Julius

Edited by: Julius Bussche on Jul 29, 2009 5:55 PM

[tim_alsop]

Julius,

I had never suggested that the exit would be implemented inside each transaction - if such an exit exists then it would be best implemented inside the SAP code (e.g. in kernel) and invoked just before the abap code for the specific transaction is run - perhaps after any authorisation checks have been completed.

Thanks,

Tim

[WolfgangJanzen]

>

> They told me they cannot give me any details on how they do this because it is confidential information.
> 
> So, without any clear way to run security code (which would re-authenticate the user) when a transaction is executed by a user there doesn't appear to be a solution to this problem available today. Maybe one day SAP will improve their product and provide a clear and secure interface to allow vendors/customers to develop this functionality.

1. That (unknown) vendor is giving excuse for not disclosing any details (actually: their "solution" must be implemented in ABAP - so you can always reverse-engineer what they are doing). Anyway, I'm not aware of any hook (user-exit, Badi, etc.) - and it would surprise me if there would be any - because the coding is in the kernel.

2. If there would be really demand for such a feature, then it should be submitted as development request through the official channels. I agree with Tim that in such a case either SAP will implement and provide a solution on its own - or provide a proper interface to be used by partners / customers.

3. I strongly believe in declarative approaches (rather than in programmatic ones): it should be customizable if a re-authentication is required each time a transaction / service / application is started. It should be understood that this is contradictory to Single-Sign-On. I don't think that each and every application developer should implement a programmatic authentication (with the risk that we end up with many different implementations).

[Former Member]

> 3. I strongly believe in declarative approaches (rather than in programmatic ones): it should be customizable if a re-authentication is required each time a transaction / service / application is started.

In SE93 there is the possibility to add / change additional authorization checks at the start of the transaction, but it is not water-tight by any means and is usefull only for plausibility checks (such as the activity, but without any other fields for which the value is not known yet).

I don't think it is a good idea to additionally add the option of exit-coding. Exits cause enough problems already... -> now folks would be able to add (for example) global constants and performance inconsiderate selects already at the start of the transaction and cause trouble even with the selection screen coding as well. Not even variant transactions can cause that many problems and security urban-legends...

Cheers,

Julius

[WolfgangJanzen]

>

> I don't think it is a good idea to additionally add the option of exit-coding. Exits cause enough problems already... -> now folks would be able to add (for example) global constants and performance inconsiderate selects already at the start of the transaction and cause trouble even with the selection screen coding as well. Not even variant transactions can cause that many problems and security urban-legends... 
> 
> Cheers,
> Julius

Well, guess why there is no user-exit which is executed DURING authentication ...

Any bug in such custom code would have serious impacts - and SAP might be unable to help (at least remotely).

That's why certified partner solutions (which can be activated / deactivated via offline configuration tools) are the better choice.

[tim_alsop]

>

> Well, guess why there is no user-exit which is executed DURING authentication ...
> Any bug in such custom code would have serious impacts - and SAP might be unable to help (at least remotely).
> That's why certified partner solutions (which can be activated / deactivated via offline configuration tools) are the better choice.

Agreed. However, the partner needs SAP to provide the interface so they can develop a solution which can then be certified by SAP before selling it to SAP customers.

[WolfgangJanzen]

>

> >

> > Well, guess why there is no user-exit which is executed DURING authentication ...
> > Any bug in such custom code would have serious impacts - and SAP might be unable to help (at least remotely).
> > That's why certified partner solutions (which can be activated / deactivated via offline configuration tools) are the better choice.

>

> Agreed. However, the partner needs SAP to provide the interface so they can develop a solution which can then be certified by SAP before selling it to SAP customers.

SAP does provide such interface and certification programs - e.g. for SNC and SSF.

But there's no interface / certification for "transaction start hooks" (and I doubt that there will be one - but that's just my personal 5 cents).

[WolfgangJanzen]

> Anyway, I talked with the vendor who has a solution that offers re-authentication when a transaction is started. They told me they cannot give me any details on how they do this because it is confidential information. This surprises me because any company or person serious about security and wanting to evaluate their product would need to know how it works.

Well, according to the publically available documentation (unfortenately I've only found one in German) the concepts seems to be like this:

"Über ein Generierungsprogramm wird die Standardberechtigung zum Ausführen von geschützten Transaktionen entfernt und durch die bioLock Berechtigung ersetzt. Alle Mitarbeiter, die eine entsprechende Rolle zugewiesen bekommen

haben, können die Transaktionen somit nur noch über das Security Menü starten."

English (rough translation):

"Using a generator tool the standard authorization for transaction starts will be removed for the (selected) protected transactions and will be replaced by the bioLock authorization check. All employees who are assigned to an appropriete role will then be able to start those transactions only by using the Security Menu".

This reveals how that solution works:

- remove S_TCODE authorizations

- force users to use a special transaction launch pad ("Security Menu")

- inside that custom transaction launch pad own checks will be performed

- finalls that launch pad starts the transaction (via CALL TRANSACTION, I assume)

So, no mystery - but it might not work reliably:

transactions which perform own AUTHORITY-CHECKS inside (e.g. SM59 checking on S_TCODE) will fail to work.

For me that would be reason enough for not certifying such a solution. But anyway: there is no interface provided, so there's also nothing to certify.

Cheers, Wolfgang (acting as private person)

[tim_alsop]

Wolfgang,

Thankyou for solving the "mystery". I think it is perhaps a good idea to return to the oriignal question asked in this thread, asked by Karthik. I understand he wants to re-authenticate users when certain transactions are run. In conclusion, this is not possible using SAP software as it is today, unless he is willing to accept and use the same method that the third-party product uses, which would mean he has to replace the authorisation checks performed by SAP with his own.

If the number of transactions which require re-authentication are small (e.g. 2 or 3) perhaps Katrhik would be interested to change these transactions so they call some code which re-authenticates the user (using SNC), and then make sure that his new modified transaction code is used instead of the SAP supplied code ? I know this approach is ugly, and has many issues which need to be considered, but it might be something which Karthik is willing to undertake. It's worth mentioning anyway...

Thanks,

Tim

[Former Member]

> So, no mystery - but it might not work reliably:

I think it can be stated with certainty that there will be a whole bunch of hacks to hose this solution.

There are easy ones (like menu options within transactions) but I can think of another cool one based on the slide deck in the demo -> it looks to me like there is a SAPGUI_PROGRESS_INDICATOR waiting to catch the action of the user. This would imply that there is a function module on the application server side waiting to run that which the client has successfully requested.

I wonder what the import parameters of that function module are?

I also agree with Tim that we might be loosing Karthik here a bit...

Cheers,

Julius

[Former Member]

Dear All,

Thanks to all of you for putting your thoughts and suggesting a solution for this requirement.The conclusion here, as i understand is as below:

1. The SAP provide TCODE's cannot be used for this requirement.

2. I need to create custom zcodes out of the existing tcodes and then call the Re-authentication fuctionaltiy on them as and when required.

3. Tthe original tcode will still be available and is vulnerable for misuse.

Please correct me if am wrong over here in understandign your suggestions.

Regards,

Karthik

[Former Member]

> 1. The SAP provide TCODE's cannot be used for this requirement.

No. The SAP provided mechanism to start a tcode cannot be manipulated - hence you cannot add your own code there. You can only add additional authorization-checks (SE93) or disable the authority-checks (SU24 / SE97).

> 2. I need to create custom zcodes out of the existing tcodes and then call the Re-authentication fuctionaltiy on them as and when required.

Yes, but if it is providing the same functionality as the original tcode, or BAPI's etc for this step in the business process - then those will still work as well and could be started as transactions, reports, function modules.

> 3. Tthe original tcode will still be available and is vulnerable for misuse.

No, it is not misuse. It is the standard system which is still there behind the cosmetic presentation of having another layer of authentication on it. If the user has the correct authorizations to use functionality and is already logged on, then chances are very good that they will be able to do so - regardless of whether they are authorized for the tcode or not.

Basically it is like giving the user a SAP_ALL minus S_TCODE profile and then expecting to control their access via the menu of a role.

It does not work that way and is pre-destined to have holes in it - from the view of your expectations.

Cheers,

Julius

[Former Member]

I thank all the experts who partcipated in this thread and it was very informative for me.

Regards,

Karthik