点击此处---> 群内免费提供SAP练习系统(在群公告中)
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
大家好,
在我看来,这应该在Fiori设置和配置文档中,但是如果是这样,我将找不到它。 我们处于将Fiori前端服务器设置为中心部署的沙盒阶段。 目的是让该系统运行Fiori Launchpad(和相关应用程序),并位于我们的ECC后端和员工门户之间的 。
但是,我们如何在FES系统中管理用户? 我们需要在那里重新创建所有ECC用户吗? 目前,我们的Portal使用ABAP后端作为其UME,因此我们不在Java环境中维护单独的用户,并且此设置非常有效。 用户登录到门户网站,他们透明地使用了来自ECC的数据等。 我希望只是插入FES,并使其成为Portal用户使用的主要应用程序。
但是我还没有弄清楚如何让FES像Portal一样使用ECC作为其UME。
我已经看到很多博客,Wiki和有关设置SSO的讨论-这不是问题。 到目前为止,所有这些讨论均假设用户存在在FES和ECC系统(和/或Portal)中。 讨论中谈到了ABAP系统中的用户自动创建,但是尚不清楚如何处理用户无效。
我们没有NWSSO的许可证(也不可能很快购买)。 我们尚未实施IdM(尽管也许有一天)。 我们处于Windows Active Directory环境中,并且我熟悉设置SPNEGO以为门户网站启用SSO(我们没有针对SAPGUI用户的SSO,因为...有关许可的信息,请参见上文),并且我熟悉 使用登录票据进行从门户到ECC的传递身份验证。
我们大约有8000个用户,并且营业额很多。 几乎每天都有人被雇用,解雇或转移。 因此,我真的更希望将它们都放在一个地方,今天就是ECC ABAP系统。
我们主要是在NetWeaver 7.5环境中:NW Java 7.5上的门户网站,EhP8/NW ABAP 7.5上的ECC,以及迄今为止ABAP 7.52上的沙盒FES 4.0。 一切都在单个Active Directory域中运行。 大多数用户将在防火墙内部并使用域成员计算机。 有一天我们想扩展到移动设备,但这不是第一要务。
那我们有什么选择? 我们是否必须首先实现另一个系统才能成为身份提供者? 这样甚至可以解决不希望重复所有这些用户以及所有持续的用户管理的问题吗? 还是这不可避免? 实施SAML2可以解决此问题吗,还是仅用于管理SSO而不能管理用户配置或映射等? 我还没有玩过SAML2。
感谢和欢呼,
马特
嘿,马特
我想知道您是否使您在这里的问题定义与无法完成的事情过于复杂。
FES最终实际上是一个ABAP系统,您的目标是提供和授权,以便回到SU01和PFCG的世界中,因为您需要对用户进行身份验证以访问FLP并进行授权 他们可以执行哪些图块/应用程序(目录和服务),并可能向他们提供Fiori组以默认设置其主页设置。 我不会像门户网站系统那样对待ABAP系统
我还没有看到SAML断言为ABAP系统创建用户,但是SSO不是我的强项。
您可以考虑的选项:
1。 LDAP集成,用于用户配置
2。 当您的ECC中发生SU01更改以执行FES中的BAPI来创建用户时,自定义存在(使用PRNG_CUST设置)。 在ECC中建立PFCG shell角色,该角色将成为FES中的PFCG角色,并在它们之间进行复制。 这样,所有维护都将保留在ECC中,并且不会直接创建任何用户。
3。 做选项2,但是只是建立在z程序上并安排它定期运行(向客户看了这个,但是想知道为什么他们不调用现有的BAPI)
4。 放入CUA,以通过ECC作为主客户端供应给FES。
此外,如果您的身份验证需要EXTID_DN事务中的SNC条目,则可以通过计划程序/IWFND/USER_MAP来自动执行此操作
作为设置的一部分,将需要在ECC和FES之间建立可靠的系统配置。
您当然拥有IdM和GRC选项,但是您已经提到了这将不会发生 。
我是否误解了您的问题?
致谢
科琳
谢谢,科琳! 好的,你们俩都很有帮助。 同时,我对自己的回复做了更多的挖掘:CUA和IdM。 我暂时不做任何选择,因为我最迫切的需要是简单地启动并运行我的CIO演示,以便他可以继续担任E套件的啦啦队。 我可以通过与一两个手动配置的用户"伪造"来做到这一点-不用理会幕后的人! -然后,当我们走出沙盒阶段并更认真地去做时,我将在项目计划中花一些时间来建立用户管理方案。
目前,我倾向于使用IdM,因为最终我们还是要去那里使用它提供的其他一些功能(更容易的密码自动重置等),但是我可以从中看到 安装比CUA涉及更多的文档。
对于密码管理,我期望用户通过我们的门户访问FES的原因之一是,我们已经在门户上具有基于spnego的SSO设置。 因此,只要从FES到ECC配置了信任,SSO 就应该起作用。 对? 对。 猜猜我们什么时候到达那里。 我可以预见这条路会有一些颠簸,但是如果没有要解决的问题,那将不会很有趣,是吗?
你好,马特!
基本上,您需要一个CUA。 可以将用户分发到正确系统的东西。 然后,在CUA中,您可以决定应创建用户的系统。 我相信您可以将其与AD/LDAP集成,但是我还没有完成,所以我不能说它的可靠性。
SAML2/SSO目前不会为您带来任何好处,因为它还要求已经配置了用户。
您目前如何创建用户? 在两个地方重新键入?
CUA与IdM
---------------
IdM是预配置的路线图
CUA仅处理ABAP系统(不可能使用Java和云)
CUA是ABAP的一部分(IDOC/ALE)-没有许可证,没有其他硬件,等等
IdM是新安装的系统,因此必须构建 哪种配置选项取决于现在和将来的业务需求。 您的工作路线是什么? 他们会增加用户群,使用其他系统吗? 您目前在配置和用户身份方面是否也可以解决问题? 对于Fiori的概念验证,您可以推迟将CUA或IdM放进去是正确的。业务决策者不需要知道如何让用户存在来展示Fiori和用户体验
CUA- 哪个系统
-------------------
主要归结为基本SP级别。 主要指导是不要使用"解决方案管理器"框。 为此,谷歌或CUA上的搜索社区提出建议,并可能会从@Bernard Hochreiter中看到很多评论。您是否将FES和ECC当作大师? 问自己的问题
1。 您是否有FES(FLP)访问权限的用户不会获得ECC帐户? 从系统访问的角度来看,这种用例是Fiori Apps到外部系统等,
->,需要在SU01中为他们分配ECC系统才能登录。 如果他们没有,他们会收到一条消息,提示您您无法登录中央系统
2。 如果您仅具有FES或ECC中的用户来处理供应3,是否会有许可证成本的影响? 您目前如何向ECC供应用户? 有自动化和复制功能吗?
4。 您的维护/系统中断和高可用性是什么? 您不想陷入FES系统停滞而无法在ECC CUA中创建用户的问题,而SU01的字段设置是通过事务SCUM设置的,因此您可以选择全局维护,仅本地,建议(用户创建)和重新分配的字段 。 像参数ID之类的字段只能作为不同系统的不同PID进行局部处理。 角色/配置文件将是全局的,并且大多数地址数据都将保持一致性。 同样,在这种情况下,用户是否需要更新SU01中的任何数据(他们当前是否进入SU3并维护其联系信息)-如果这样,他们可能会失去此访问权限
希望能提出更多问题的思考。
一周热门 更多>