Role based Firefighter approach in AC 10

I am in the process of implementing "role based" FF (ID based approach not implemented as users are not comfortable to login to GRC system to execute the tcodes). I have a query about it.
If we maintain the role based FF logins, and we run risk report, still all the conflicts are found associated with that FF ids as they have the conflicting role assigned to them in SU01. So is it ok, to live with these conflict found related to FF ids. what will be the case during audit, will they accept these risks occuring for the FF can be ignored.

Hello,
I think the best approach is to mitigate the risk as Alexander describes here:
Why Role based Firefighter
Cheers,
Diego.

Similar Messages

Role Based FireFighter with GRC 10.0 (CEA)

Does anyone know how the Role Based functionality of FireFighter exactly works besides putting the application type parameter to Role Based in SPRO?
The manuals explain that the FF users log in to the remote system with their own users, but how are the FF roles or roles that are enabled for Firefighting assigned to these users and how will the log file know which activity to record?

Good question, and the answer is not pretty.
In Role-Based Firefighter Application, the firefighter ID on the target system contains the user's regular access plus his/her firefighter access.
Reporting turns on when the user runs a transaction in the firefighter role.
If the transaction is in both the user's regular access and the firefighter role, reporting will turn on because the firefighter role access is in use.
The reports only track firefighter role usage. So if a user runs a firefighter transaction but also uses access defined in the user's regular access, the only thing recorded is the transaction.
If your company is not completely married to the idea of using Role-Based Firefighter Application, I suggest you consider the ID-Based Firefighter Application. In this, there are separate firefighter IDs on the target system and a firefighter gains access to them by going into GRC and completing a form showing how the firefighter ID will be used, and then the GRC system will let the firefighter into the target system using that firefighter ID.

Role Based FireFighter

Greetings All,
We are doing SAP GRC Access Control implementation in our company. We have Modulewise Master Roles working as firefighter Roles. In emergency we assign it to a user for 24 hours. Now when we are implementing FireFighter we want to keep existing Role Model but use the funcationality of FF. Have anyone gone through this scenario, do let me know the steps we need to configure the existing model with new FF Model and AE.
Thanks in advance,
Regards,
Sabita Das

Try Firefighter roles instead of Firefighter users.
FF access via role assignments can be approved and provisioned in Access Enforcer (AE). Firefighter access can also be removed via Access Enforcer by submitting a request to remove the firefighter roles. FF access approvals are captured in the AE audit trail. The business reason for requesting/approving the access can also be captured in the comment section of AE.
FF access could be granted only after appropriate approvals EVERY time a user needs FF access. Each time a request for the FF role through AE (the request could go through a separate workflow path) and the request will be approved before being provisioned to the user. The approver can change the validity dates on the role assignment so that it can be provisioned for one day, for a week, a month, etc... An audit trail in AE will provide the approver information for historical purposes. This meets the policy of approvals every time FF access is provided instead of the 24/7 master data set-up in the original Firefighter process.
When running an SOD risk analysis on the user, the report will show the SODs the user has including their Firefighter access. (These SODs would then be mitigated per user even though they are a Firefighter.) There is a risk to the company when a firefighter can do one half of the risk on their own user ID and the second half of the risk on their Firefighter ID. Although this could still be caught, it would take some manual analysis. By using role-based Firefighter, all activities are performed and recorded under the user's normal user ID.
The Firefighter does not need to "check-out" a Firefighter ID the access is on their normal user ID.
The standard SAP audit trails have the user IDs instead of the firefighter IDs, so when researching the change, the firefighter logs don't need to be analyzed to see which user had used that Firefighter ID at that time.

Why Role based Firefighter

Hello Folks,
What is the difference between Role based and Firefighter Id based Firefighting from an organization point of view.
The general practice is to go with Firefighter ID but I want to know a situation when Firefighter Role based strategy can be an advantage over the other.
In the user guide it is not mentioned when and why Role based Firefighter should be used.
Thanks in advance,
Amol Bharti

FF access via role assignments can be approved and provisioned in Access Enforcer (AE). Firefighter access can also be removed via Access Enforcer by submitting a request to remove the firefighter roles. FF access approvals are captured in the AE audit trail. The business reason for requesting/approving the access can also be captured in the comment section of AE.
FF access could be granted only after appropriate approvals EVERY time a user needs FF access. Each time a request for the FF role through AE (the request could go through a separate workflow path) and the request will be approved before being provisioned to the user. The approver can change the validity dates on the role assignment so that it can be provisioned for one day, for a week, a month, etc... An audit trail in AE will provide the approver information for historical purposes. This meets the policy of approvals every time FF access is provided instead of the 24/7 master data set-up in the original Firefighter process.
When running an SOD risk analysis on the user, the report will show the SODs the user has including their Firefighter access. (These SODs would then be mitigated per user even though they are a Firefighter.) There is a risk to the company when a firefighter can do one half of the risk on their own user ID and the second half of the risk on their Firefighter ID. Although this could still be caught, it would take some manual analysis. By using role-based Firefighter, all activities are performed and recorded under the user's normal user ID.
The Firefighter does not need to "check-out" a Firefighter ID the access is on their normal user ID.
The standard SAP audit trails have the user IDs instead of the firefighter IDs, so when researching the change, the firefighter logs don't need to be analyzed to see which user had used that Firefighter ID at that time.

GRC 10 Role based firefighter multiple users

Hi All
We are using GRC AC 10 SP12 and have Role based EAM implemented. We are looking at way to prevent the same user from being assigned multiple firefighters or a way for approver to know that another Firefighter ID is already assigned to this user?
Thanks in advance
Regards
Vijaya

Hi Vijaya,
You can train approvers to Click on existing assignment button(in Access Request) to know the roles already assigned.
And if in your environment, FF roles has distinguished naming convention then it can easily be identified
by role owners.
Thanks,
mamoon

GRC10 Firefighter - Role-based & ID-based

GRC Gurus,
I am looking for a solution or at least theoretical discussion about a scenario in which GRC 10 system is connected to more than 1 target system and in one system I want to use FFID-based option where as in other system it is FF-Role based. For example, in a system where all the users are logging in through SAP GUI, it will be better to have FFID-based firefighter where as in system where most of the users are logging in through portal it will be better to have role-based firefighter. under GRC5.3 it was pretty simple as RTAs were independent in each separate system but in GRC10 since type of firefighter is controlled by single parameter, what will be a way to implement such hybrid approach.
Regards,
Shivraj

Thanks Anji,
Thanks for the response, I am aware of the 4000 situation, I was just wondering if someone has figured out any workaround for this. Because otherwise, it is a step backward for new version as under 5.3, systems could have been on different setups whereas under GRC10 that is not possible.
Regards,
Shivraj Singh

EAM ID based or Role based? Why settle for just one?

G'Day All,
I've raised a question in the following blog, however I would like to open it up to other people as well so they might get something out of it and in the process might share their own thoughts on the matter at hand.
ID-Based Firefighting vs. Role-Based Firefighting
So this is where I am at this point:
From what I can gather so far, my understanding of EAM ID/ROLE based is as follows:
- Id Based: Logs in using own U.ID and through GRAC_SPM accesess FFID from the GRC Server and logs into the system assigned to them (ECC, SRM, CRM etc)
Only one user at a time can use a FFID.
Firefighter need not exist in every system assigned to them due to central logon however they need to exist in the GRC system
Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing)
Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors!
Two Log ins so potential to commit fraud. (1 action using own UserID and 1 action using FFID)
Could be hard to track and find out when a fraud has been committed so can be a problem with auditors.
      ID Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs assigned to you
      ID Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> You can see the FFIDs assigned to you
- Role Based: Logs into the remote system only using U.ID, so everything gets logged against that one ID.
Multiple users can use the FFROLE at once.
Firefighter has to exist in every system assigned to them - so multiple logons.
Hard to differentiate between FF tasks and normal tasks as no login required So easy to slip up
Time consuming to track FF tasks - No Specific log reports. No Reason Codes
     R.Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs
     R.Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work
So based on this there are pros and cons in both however according to SAP only one can be used. To me personally, it makes more sense to get the best of both the worlds right? So here is my question why can’t we just use both?
    . Really critical tasks -> FFID
    . Normal EAM tasks -> FFRole
Alessandaro from the original post pointed this out:
"Per design it isn't possible to achieve both types of firefighting at the same time. It's a system limitation and hence to configurable."
Well this is what I can't seem to get my head around. For a FFID, there is a logon session so it has to be enabled and as far as I can tell there is no way around it.
However for FFRole, there isn't such limitations/restrictions like starting a separate session. FFRole is just assigned to an end user for him/her to perform those tasks using their own user ID.
So in what way is it different from any of their other tasks/roles, other than the fact that they've got an Owner/Controller assigned to the FFRole? and
What is stopping us from using it when ID based is the default?
If I were to do the following does it mean I can use both ?
    . Config Parameter: 4000 = 1 (GRC System) -> ID Based
    . Config Parameter: 4000 = 2 (Plug-In) - > Role Based
Please excuse me if my logic is a bit silly, Role Based firefighting is only done on Plug-in systems so the following should work just fine:
   . Config Parameter: 4000 = 2 (Plug-In) - > Role Based
However for ID based, it is a Central Logon, so the following is a must:
    . Config Parameter: 4000 = 1 (GRC System) -> ID Based
Which means both ID/Role based can be used at the same time, which seems to be working just fine on my system. Either way I leave it you experts and I hope you will shed some light on it.
Cheers
Leo..

Gretchen,
Thank you for thoughts on this.
Looks like I'm failing to articulate my thoughts properly as the conversation seems to be going in a different direction from what I am after. I'll try once more!
My query/issue is not in regards to if/what SAP needs to do about this or why there isn't more support from Companies/Organizations and not even, which one is a better option.
My query is what is stopping us(as in the end users ) from using both ID/Role based at the same time?
Now before people start referencing SAP documentation and about parameter 4000, humour me with the following scenario please. Again I would like to reiterate that I am still in the learning phase so my logic might be all wrong/misguided, so please do point out to me where I am going wrong in my thought process as I sincerely would like to know why I am the odd one out in regards to this.
Scenario
I've created the following:
FFID
FFROLE
Assigned them to, two end users
John Doe
Jane Doe
I set the Configuration Parameters as follows:
IMG-> GRC-> AC-> Maintain Configuration Settings -> 4000:1 - ID Based
IMG-> GRC (Plug-in)-> AC-> Maintain Plug-In Configuration Settings-> 4000:2 - Role Based
User1
John Doe logs into his regular backend system (ECCPROD001)-> executes GRAC_SPM-> Enters the GRC system (GRCPROD001)-> Because the parameter is set to ID based in the GRC Box, so he will be able to see the FFID assigned to him-> and will be presented with the logon screen-> Logs in -> Enters the assigned system (lets say CRMPROD001) At this point the firefighting session is under progress
User2
Jane Doe logs into her regular backend system (ECCPROD001) -> (can execute GRAC_SPM to check which FF Role has been assigned to her but she can see that in her regular menu, so there is no point) -> Executes the transactions assigned in FFROLEThis is done at the same time while FFID session is in progress
So all I want to know is if this scenario is possible? if the answer is No, then why not?
I physically carried out this scenario in my system and I had no problems(unless I am really missing the plot here), which brings me back to my original question: Why settle for just one?
Again to reiterate I am not getting into the efficacy or merits of this or even if one should use this. Just want to know if it is possible/feasible or not.
So there you have it. That's the whole enchilada(as they say there in Texas). I tried to word my thoughts as concisely as I can, if there are still any clarifications, more information you or anyone else reading this would like, please do let me know.
Regards,
Leo..

Difference between ID and Role based Administration - Firefighter 5.3

In GRC AC 5.3 Firefighter, security guide, there are two sections for role design,
1. Firefighter Role based Administration
2. Firefighter ID based Administration
Can someone explain what is the difference between the two?
I have read the documentation, but it does not have a clear description of the
differences between the two.
Please help.
Thanks

HI Prakash,
Though both of them eventually achieve the same function, that is giving access rights to the user for a certain period under monitring these differ based on the following:
1. Firefighter Role based Administration
You identlfy a particular role as a firefighter role and give it to the user.
2. Firefighter ID based Administration
You create a separate user altogether and give the normal dialog user, the access to this user's authorization.
For the implication that both of these have and the differences or comparisons between using 1 & 2, I would suggest you do a bit of Mock testing for both of these. Also, there are a lot of posts related to this on the forum already, which you can refer to, for getting a more detailed idea on this topic. Unlimately, it depends on organization to organization which methodology they folow as per what suits them, according to features which both have. But generally what is preferred is Number 2.
Regards,
Hersh.

Renumbering with ACL-Friendly Role-Based Addressing or...?

We are a mid-sized manufacturing firm operating out of three locations and we are in the process of making plans to restructure and renumber our networks so as to better facilitate automated configuration management and security, in addition to easing our deployment of IPv6. Currently, at each site the L3/L2 boundary resides at the network core, but increasing traffic/chatter has us considering moving the L3/L2 boundary to the access layer(s), which consist of 3560-X units in the wiring closets that are supporting edge devices either directly or via 8-port 3560-C compact switches in the further reaches of our manufacturing and warehouse spaces.
As we contemplate moving to a completely routed network, the big unknown we're struggling with is whether or not it is safe or even desirable to abandon ACL-friendly addressing, and whether, in doing so, we can expect to run into hardware limitations resulting from longer ACLs.
Currently, each of our site-wide VLANs gets a subnet of the form 10.x.y.0/24, where x identifies the site and y identifies the class of equipment connected to said VLAN. This allows us to match internal traffic of a given type with just a single ACE, irrespective of where the end-point device resides geographically. Moving L3 routing decisions out to the access switches will require that we adopt smaller prefix assignments, with as many as 8 distinct subnets on each of our standard-issue 3560CG-8PC compact switches. Why so many, you ask? We currently have more than 30 ACL-relevant classifications of devices/hosts - a number that will only grow with time, and to maximize the availability of all services, it is our policy to physically distribute edge devices of a given class (eg. printers, access points, etc) over as many access switches as possible.
From what I can see, we have three options, each of which present trade-offs in terms of management complexity and address utilization efficiency:
Option 1: Stick with ACL-friendly addressing, both for IPv4 and IPv6, and allocate uniform prefixes to each access switch. For IPv4, within the 10.0.0.0/8 block we would probably allocate 8 bits to the site ID (/16), followed by 6 bits as the switch ID (/22), and 7 bits to identify the equipment/host classification (/29), for a maximum of 5 available addresses for a given class of devices on a given access switch. For IPv6, assuming we have a /48 block for each site, we would use the first two bits to identify the type of allocation, the following 6 as the switch ID (/56), and the following 8 as the equipment/host classification (/64).
Option 2: Abandon ACL-friendly addressing and dynamically allocate standard-sized prefixes from a common pool to each VLAN on a given switch. The advantages of this approach are increased utilization efficiency and more addresses available within each VLAN, but it comes at the cost of non-summarizable routing tables and ACLs, and even if the hardware can handle this, it means we're talking about a more complex configuration management system and less ease in troubleshooting problems.
Option 3: Do something similar to option 1, but with the L2/L3 boundary positioned at the distribution layer rather than the access layer. I'm disinclined to go this route, as it seems to require the same, if not more, management complexity than we'll encounter with option 1, with only marginal benefits over keeping things the way they are currently (L2/L3 boundary at the network core).
Thoughts? What issues have we neglected to consider? No matter which approach we select, it shall be assumed that we will be building a system to track all of these prefix assignments, provision switches, and manage their configurations. From a standpoint of routing protocols, we would probably be looking at OSPFv2/v3. It can also be assumed that if we encounter legacy devices requiring direct L2 connectivity to one another that we already have ways of bridging their traffic using external devices, so as far as this discussion is concerned, they aren't an issue.
Thanks in advance for your ideas!
-Aaron

Hi David,
Permissions based on GUI components is a simple & neat idea. But is it rugged? Really secure? It might fall short of Grady Booch's idea of Responsibilities of objects. Also that your Roles and Access components are coupled well with Views!!!!!!!
My suggestion regarding the Management Beans is only to do with the dynamic modification which our discussion was giong forward.
If we go back to our fundamental objective of implementing a Role based access control,let me put some basic questions.
We have taken the roles data from a static XML file during the start up of the container. The Roles or Access are wanted to be changed dynamically during the running of the container. You would scrutinize the changes of Roles and access before permission during the case of dynamic modification.
Do you want this change to happen only for that particular session? Don't you want these changes to persist??? When the container is restarted, don't you want the changes to stay back?
If the answer to the above is YES(yes I want to persist changes), how about doing a write operation(update role/access) of the XML file and continue your operation? After all, you can get the request to a web or session bean and keep going.
If the answer to the above is NO(no, i don't want to persist), you can still get the change role request to a web or session bean and keep going.
Either way, there is going to be an intense scrutiny of the operator before giving her permissions!!!
One hurdle could be that how to get all neighbouring servers know about the changes in roles and access??? An MBean or App Server API could help you in this.
May I request all who see this direction to pour in more comments/ideas ? I would like to hear from David, duffymo, komone and jschell.
Rajesh

ADF UIX Role Based Access Control Implementation

Hi,
Can anybody suggest a detailed example or tutorials of how to implement a role based access control for my ADF UIX application.
The application users can be dymanically added to specific roles (admin, Secretary, Guest). Based on the roles, they should be allowed to access only certain links or ADF entity/view operations. Can this be implemented in a centralized way.
Can this be done using JAZN or JAAS. If so, Please provide me references to simple tutorial on how to do this.
Thanks a lot.
Sathya

Brenden,
I think you are following a valid approach. The default security in J2EE and JAAS (JAZN) is to configure roles and users in either static files (jazn-data.xml) or the Oracle Internet Directory and then use either jazn admin APIs or the OID APIs to programmatically access users, groups and Permissions (your role_functions are Permissions in a JAAS context).
If you modelled your security infrastructure in OID than the database, an administrator would be able to use the Delegated Administration Service (DAS), as web based console in Oracle Application Server. To configure security this way, you would have two options:
1. Use J2EE declarative security and configure all you .do access points in web.xml and constrain it by a role name (which is a user group name in OID). The benefit of this approach is that you can get Struts actions working dirctly with it because Struts actions have a roles attribute.
The disadvantage is that you can't dynamically create new roles because they have to be mapped in web.xml
2. Use JAAS and check Permissions on individual URLs. This allows you to perform finer grained and flexible access control, but also requires changes to Struts. Unlike the approach of subclassing the DataActionForward class, I would subclass the Struts RequestProcessor and change the processRoles method to evaluate JAAS permissions.
The disadvantage of this approach is that it requires coding that should be done carefully not to lock you in to your own implementation of Struts so that you couldn't easily upgrade to newer versions.
1 - 2 have the benefit of that the policies can be used by all applications in an enterprise that use Oracle Application Server and e.g. SSO.
Your approach - as said - is valid and I think many customers will look for the database first when looking at implementing security (so would I).
Two links that you might be interested in to read are:
http://sourceforge.net/projects/jguard/ --> an open source JAAS based security framework that stores the user, roles and permissions in database tables similar to your approach
http://www.oracle.com/technology/products/jdev/collateral/papers/10g/adfstrutsj2eesec.pdf --> a whitepaper I've written about J2EE security for Web applications written with Struts and JavaServer pages. You may not be able to use all of it, but its a good source of information.
Frank

RBAC / Role Based Security Set Up in R12

We are working with a 3rd party consulting organization to implement Role Based Access Control in E-Business Suite R12. We have approximately 50 users and with 35 responsibilities today and are currently in the process of designing our role based security set up. In advance of this the consulting company has provided us with effort estimates to cutover from the current responsibility structure to RBAC. We are told this must be done while all users are off the system. The dowtime impact to the business is very high, expecially considering our small user base.
With RBAC cutover downtime estimates such as these I can't understand how any company larger than ours could go live with it?
Does anyone have previous Role Based Access Control implementation experience in EBS R11i or R12 and could provide some insight on their experience and recommendations, best practice for cutover to mitigate impacts to the business as we cannot accept the 90 hours of downtime outlined by the consulting company below?
Disable users old assignments:
*12.00 hours*
Disable Responsibilities targeted for the elimination:
*12.00 hours*
Disable Responsibilities targeted for the elimination:
*16.00 hours*
Setup OUM options and profiles:
*6.00 hours*
Setup Roles and Hierarchies:
*14.00 hours*
Grant Permissions:
*12.00 hours*
Setup Functional Security and disable the obsolete responsibilities:
*12.00 hours*
Setup Data Security and disable the obsolete data accesses:
*6.00 hours*
Total *90 hours*
Note - all activities must be performed sequentially*
Any advice or experiences you could share would be extremely valuable for us. Thank you for taking the time advance to review & respond.

On Srini`s comments "Creating Roles.. will have to be done manually "... I would like to know will the same approach be followed for PRODUCTION instance also. Say if we need to create 35 responsibilities and 50 roles so should this be done manually in PRODUCTION.
I have not worked on this but I know that in my previous company this was done using scripts. Need to find more on this.

[JSF 1.2] - Role Based Web Application: Whats the correct way of doing it?

Hello,
i have a web application that in some pages is role based. I have two database tables, Role and Permissions. Role can have 1..N Permissions and vice versa.
In one page i need to render some forms depending on user role.
What is the best approach to this?
1. I have a sessionBean and on login load all the permissions (it's less secure but faster) based on user role;
2. Everytime i use rendered="#{sessionBean.checkPermissions['can-create']}" i query the database. This checkPermissions gets the user role and retrieve all permissions of that user on demand;
The first option is faster but while the user is logged if permissions changes we might have problems.
The second, if i user 3 rendered attributes i do 3 queries to the database.
Is rendered attribute the correct implementation?
Regards.

Yes, the rendered attribute is the correct way to accomplish this.
As to the question of caching the result or querying the database each time, that is something that needs to be answered on an application by application basis.

SPM 5.3: Role Based FF

Dear all,
Has anyone used the role based fire-fighter before? I have assigned a role to the firefighter owner in /VIRSA/VFAT, but, unlike the firefighter ID, there is no logon button. Can someone explain how to use role based fire-fighter ?
Thanks & regards,
Debbie

Hi Debbie,
I am assuming that the firefighter role has been created and mapped for the respective user. As of my understanding there is no separate log in tab unlike the user based firefighter. Only the audit trails can be found in CUP for the reference purpose. Like any other T-code execution, he can also perform the firefighter task in the same ID. Therewould be no separate logon button here.
If your question is anything else, please revert back.
Hi Experts,
Please correct me, if I am wrong.
Thanks,
Gurugobinda
Edited by: gurugobinda harichandan parida on Sep 23, 2009 5:34 PM
Edited by: gurugobinda harichandan parida on Sep 23, 2009 5:34 PM

To run OHS at port 80 using solaris role based access control

Hi.
I already know & have done setuid root to ohs/bin/.apachectl to allow ohs to listen to port 80. Now on a new OFM 11.1.1.4 install, I want to use Solaris Role Based Access Control (RBAC) instead. Is it possible? RBAC does work as I can run a home built apache2 httpd at port 80 withOUT suid root.
On Solaris 10, I enabled oracle uid to run process below port 1024 using RBAC
/etc/user_attr:
oracle::::type=normal;defaultpriv=basic,net_privaddr
Change OHS httpd.conf Listen from port 8888 to port 80.
However, opmnctl startproc process-type=OHS
failed as below with nothing showing in the diag logs:
opmnctl startproc: starting opmn managed processes...
================================================================================
opmn id=truffle:6701
0 of 1 processes started.
ias-instance id=asinst_1
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ias-component/process-type/process-set:
ohs1/OHS/OHS/
Error
--> Process (index=1,uid=187636255,pid=25563)
failed to start a managed process after the maximum retry limit
Thx,
Ken

Just to add my two cents here.
The commando used on Solaris to assign the right privilege to bind TCP ports < 1024 is:
# usermod -K defaultpriv=basic,*net_privaddr* <your_user_name>
Restart the opmnctl daemond.
After that OHS/Apache user can bind to lower TCP ports.
Regards.
Edited by: Tuelho on Oct 9, 2012 6:05 AM

What is the mean of using Portal with Role Based security as entry point

Hi Experts we have requirement of integration of Portal and MDM
I am completely new to the MDM. So please give me some idea , what is the meanin for following points.
1) Using the Portal with Role Based security as entry point for capacity and Routing Maintaince(These two are some modules).
2) Additionally , Portal should have capability to enter in to the MDM for future master data maintence. Feeds of data will need to be come from SAP 4.6c
Please give me the clarity of what is the meanin of second point
Regards
Vijay

Hi
It requires the entire land scape like EP server and MDM server both should be configured in SLD.
Your requirement is maintaing and updating the MDM data with Enterprise portal.We have some Business Packages to install in Portal inorder to access the functionality of MDM.
Portal gives you a secure role based functionality of MDM through Single sign on (login into the portal access any application) to their end users.
Please go through this link
http://help.sap.com/saphelp_mdmgds55/helpdata/EN/45/c8cd92dc7f4ebbe10000000a11466f/frameset.htm
You need to develope some custom applications which should be integrated into the portal to access MDM Server master data
The estimation involves as per your requirement clearly
Its depends upon the Landscape settings, Requirement complexity,Identify how many number of custom applications need to be developed
Regards
Kalyan

Role based Firefighter approach in AC 10

Similar Messages

Maybe you are looking for