topic Re: SICF Access for Web Dynpro Development in Application Development and Automation Discussions

SICF Access for Web Dynpro Development

Former Member — Thu, 05 Mar 2009 17:56:11 GMT

Developer wants access to SICF to be able to test any Web Dynpro Development. Currently no developer has access and Basis only gives access when requested - and only for short time. I believe developers should have access. Wondering how others have this setup. Thanks!

Re: SICF Access for Web Dynpro Development

allaine_tabilin — Thu, 05 Mar 2009 20:17:02 GMT

Hi,

We normally enabled all services on SICF in development enabled (as per SAP recommendation). This will allow them to develop programs/reports/services continuously (especially, since most of the time they will just try stuff if it works). Authorization access is also given so they can fully do their activities --that is, they have acces all the time for this transaction. (There are no connections to production or test environments or to an external URL)

On Test/QA systems, the services are enabled only if upon request (by this time or when the developers has finished the code and have requested it be transported). They do have access to SICF (but cannot run the test or activate the service) as the service should now be tested as how the users will be using it (either thru portal or thru a URL link/shortcut from an application --- not via SICF).

Thanks,

Allaine

Re: SICF Access for Web Dynpro Development

Former Member — Thu, 05 Mar 2009 20:19:23 GMT

Thanks!

Re: We normally enabled all services on SICF in development enabled (as per SAP recommendation).

Is there a note with the recommendation?

Re: SICF Access for Web Dynpro Development

Former Member — Thu, 05 Mar 2009 20:43:54 GMT


> Re: We normally enabled all services on SICF in development enabled (as per SAP recommendation).  
> 
> Is there a note with the recommendation?

I would also be curious. Generally, the recommendation that what you don't use should not be activated / enabled / configured / installed / etc...

But the delevelopers (you have to trust them) should be able to activate and configure these ICF objects in DEV.

At this point, many customer realize that the developer themselves should not have SAP_ALL in PROD... nor access to any other user in PROD other than their own ID for ESS and perhaps their cost center reports... and the passwords of the service users which are used should be managed differently in PROD than what they are in DEV, additionally to the authorizations of the service users in PROD being restricted sufficiently that they cannot do other more fancy tricks which can be launched from a development system.

I agree with Allaine's post for the rest of it though.

Perhaps another tweak you can use is that if there are problems in PROD, then they don't need to test these from SICF. They can set an external break-point in the code for the service user, whom you temporarily give access to debug itself. The developer can then start the service as any other user of it would, and debug the session of the service user from there (not via SICF).

Often complexity is the problem though and they will want to get rid of as much of it as possible by adding more access. Luckily, in higher releases there are the new features of "terminal debugging" and "application layer debugging" (7.00 EhP1 if I remember correctly), so they will hopefully prefer the external debugging to SICF anyway once they learn how to use it...

Please show this thread to your developers. It would be usefull and interesting to learn from them where they see the bottle-necks, and discuss solutions.

Cheers,

Julius

Re: SICF Access for Web Dynpro Development

Former Member — Thu, 05 Mar 2009 20:50:04 GMT

It is not a bottleneck and it is not for production.

This is for developement only.

If a developer creats an app via SE80 - which does the same in ICF for the service - then SICF access is required.

Personally I think it is not a big deal in a development box for them to have. But I was hoping there was some SAP guidance or OSS note, etc.

Re: SICF Access for Web Dynpro Development

Former Member — Thu, 05 Mar 2009 21:11:19 GMT

> If a developer creats an app via SE80 - which does the same in ICF for the service - then SICF access is required.

Are you sure? Or is the tcode check only appearing somewhere in a trace?

If that is true, then ICF service developers will anyway be able to start SICF directly. Please check the coding location of the check from the trace, if it is calling FM AUTHORITY_CHECK_TCODE (which I suspect it is...) then verify in SE97 that an SE80 developer can use (limited, coded...) SICF functionality from other contexts without starting it directly.

What you can also do is protect the ICF services using the authorization group concept (including those you are not using...). If the developer wants to use one (in a new development) then it should be released for them by granting them access to it (authorization object S_ICF_ADM in their role) for development work and then ideally object S_ICF added to the service user they are using for development as well. If they are developing the role for the application together with the application coding development (this is the ideal scenario in my opinion for a knowledgable developer) then give them that access as well in PFCG for the role they are developing.

I think it can safely be said that most developers can be trusted, but also to do stupid things though... and they enter their own user ID in the connection data..

That is a reality. If you trust them and train them and collaborate with them to improve security - then they will be your best friends and understand more about security as well (to protect themselves from their own user ID's...).

This is a very interesting topic. Thanks for raising it.

Cheers,

Julius

ps: I don't like posting links, because I see it as an insult to the person who asked the question as not having done a search and not knowing what they are talking about. But for the benefit of those who use the search and find this thread... please read this documention (or the one which is relevant for your release - I choose a reasonable release level...).

http://help.sap.com/saphelp_nw04s/helpdata/en/61/d93822a88e15489a9391f309767366/content.htm

Edited by: Julius Bussche on Mar 5, 2009 10:31 PM