Biller direct query

[Former Member]

Hi All,

We have the below requirement:

"Remove u201CEditu201D access from Address data section from BD external users' role"

Can anyone help me out that which auth. object will be responsible for the above access?

Thanks

Peeyush

[Former Member]

First of all what system, transaction or screen are they talking about?

If they haven't specified this to you then you don't have much to work on.

[Former Member]

Alex,

They have just specified:

When external customers use BD frontend portal ,they shouldnot be able to change the address data from the "edit" option available in the frontend.

And in additon they have provided with the screenshots of the BD frontend portal showing the "edit" button below the address"

Peeyush.

[Former Member]

Hmm, I don't have access to that type of system so I've not got any good ideas unfortunately

[Former Member]

No idea either, but what happens when they click on the button?

Some Java applications use authority in their methods, so you can distinguish between starting an application and using it.

In the ABAP system, this is sometimes checked upfront to determine whether the button is visible or not. This is very user friendly but confuses security folks who only follow ST01 trace results.

Cheers,

Julius

[Former Member]

Hi Peeyush,

You might want to restrict the external user (Named user) for RFC Function group :

APAR_EBPP_KNB1_EXT - FSCM Master Data Customer Enhancements

If you have only the reference user assigned to the Named user, then probably you might want to restrict the BD reference user role, as this is an update call, probably might not go to the BD pool user.

Check if this helps

Cheers

Abhishek

[Former Member]

I thought the reference user concept is always optional from an application perspective?

A direct (local) assignment of a profile is possible for wizards --> function SUSR_INTERFACE_USER.

If installation wizards use the reference user, then this is not a good indicator in my opinion...

Cheers,

Julius

[Former Member]

Hi Julius,

For Biller Direct, I think it is defaulted rather than recommended ( I will check this) . The XCM configuration guide also explains how to setup the connections. Even the [sec guide|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f03e38e4-7a55-2a10-d9a1-f129b31f5d7e] explains this setup. That makes me think this is defaulted.

For now, we are still configuring it, so don't know what implications it will have. Also, didn't get to explore its all options for BD, as its pretty new to all.

Works ok for now..managed to get it working for some testing

Thanks

Abhishek

Edited by: Abhishek Belokar on Jun 10, 2009 3:55 PM

[Former Member]

Oh yes, i understood you now. Yes, the reference user concept is optional from an application perspective, I was thinking about the pool and the named user, where I got confused because of the terminology of biller direct.

For BD, SAP recommends using the reference user concept for web users.

Extract ~

Recommendation

· Assign the authorizations exclusively to the reference user master records, and not

direct to the user master records of the individual Web users.

[Former Member]

Thanks!

It looks like a recommendation to make the number of web users more scalable by only assigning the role to one reference user.

Initially I thought it was a setup wizard which was automatically doing this (creating the reference user and assigning it to a pool user - which also checks the role assignment authorization...). This is not the case.

Cheers,

Julius

[Former Member]

Hi Julius,

It indeed makes it very scalable.

Am just wondering if we get a requirement for a variance in authorization between web users, then the reference users will start multiplying. Am hoping this will not be the case.;-)

Thank you

Abhishek

[Former Member]

One could still use personalization, PIDs, personell numbers, business parter attributes, the creator of the document selected, etc...

The bugger is that when you mix several concepts in the same system (and for the same objects or access to data) then sooner or later parts of them clash or become incompatable or are (officially) reclassified as "not security relevant".

Cheers,

Julius