点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)专家您好, 我花了一些时间试图...
点击此处---> 群内免费提供SAP练习系统(在群公告中)
加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)
专家您好,
我花了一些时间试图找出导致问题的原因,但没有结果,所以我想把问题发到这里,希望有人能帮助我。 我开发了一个多目标应用程序,该应用程序由SAP UI5和Java应用程序组成。 Java应用程序由UI5应用程序调用,它们通常是一起构建和部署的。 到目前为止,在未经身份验证的测试中,UI5应用程序能够调用Java服务,并且每个应用程序URL也可以将该Java服务称为独立服务器。
但是,一旦我使用web.xml文件中的FORM登录方法保护了Java应用程序,即使成功执行了SAML2身份验证,也无法再访问该应用程序。 我在Eclipse中测试了完全相同的Java应用程序,并将其在本地服务器上运行,并且身份验证按预期工作。
这是我的web.xml:
<?xml version =" 1.0" encoding =" UTF-8"?>电子邮件 <登录配置>FORM <安全性约束>受保护的 /* <角色名称>所有人 <安全角色> 所有SAP Cloud Platform用户 所有人
Java应用程序非常简单,只有两个servlet,而MailServlet是执行大部分工作的一个。 它基于Maven,并使用相应的Maven命令构建。
单击应用程序URL后,立即执行SuccessFactors(已配置的IDP)登录,并在此之后立即显示此错误:
在日志中显示此错误消息:
2020 02 13 12:23:34#+ 00#ERROR#com.sap.core.jpaas.security.saml2.sp.loginmodule.SAML2JPaaSLoginModule ## anonymous#https-jsse-nio-8041-exec-7# na#ssjrihy0t7#candidatereportmail0#web#ssjrihy0t7#na#na#na#na#无法处理SAML消息com.sap.security.saml2.sp.sso.exception.BadCredentialsException:接收到的SAML2Response的发行者不是受信任的身份 提供者。 没有针对IdP'https://netweaver.ondemand.com/services'的配置 在com.sap.security.saml2.sp.sso.LoginResult.throwBadCredentialException(LoginResult.java:268) 在com.sap.security.saml2.sp.sso.SAML2Authentication.validateResponseAssertion(SAML2Authentication.java:627) 在com.sap.security.saml2.sp.sso.SAML2Authentication.validateResponseAssertion(SAML2Authentication.java:609) 在com.sap.core.jpaas.security.saml2.sp.loginmodule.SAML2JPaaSLoginModule.login(SAML2JPaaSLoginModule.java:181) 在sun.reflect.NativeMethodAccessorImpl.invoke0(本机方法)处 在sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 在sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 在java.lang.reflect.Method.invoke(Method.java:498) 在javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) 在javax.security.auth.login.LoginContext.access $ 000(LoginContext.java:195) 在javax.security.auth.login.LoginContext $ 4.run(LoginContext.java:682) 在javax.security.auth.login.LoginContext $ 4.run(LoginContext.java:680) 在java.security.AccessController.doPrivileged(本机方法) 在javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) 在javax.security.auth.login.LoginContext.login(LoginContext.java:587) 在com.sap.core.jpaas.security.auth.service.internal.LoginContext.login(LoginContext.java:110) 在com.sap.security.auth.service.webcontainer.internal.DirectAuthenticatorHelper.authenticate(DirectAuthenticatorHelper.java:277) 在com.sap.cloud.runtime.impl.bridge.security.helper.IndirectAuthenticatorHelper.authenticate(IndirectAuthenticatorHelper.java:92) 在com.sap.cloud.runtime.impl.bridge.security.AbstractAuthenticator.doAuthenticate(AbstractAuthenticator.java:250) 在org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:633) 在com.sap.cloud.runtime.impl.bridge.security.AbstractAuthenticator.invoke(AbstractAuthenticator.java:206) 在com.sap.cloud.runtime.kotyo.tomcat.support.CookieValve.invoke(CookieValve.java:30) 在org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) 在org.apache.tomee.catalina.OpenEJBSecurityListener $ RequestCapturer.invoke(OpenEJBSecurityListener.java:97) 在org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678) 在org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:678) 在com.sap.core.tenant.valve.TenantValidationValve.invokeNextValve(TenantValidationValve.java:182) 在com.sap.core.tenant.valve.TenantValidationValve.invoke(TenantValidationValve.java:97) 在com.sap.js.statistics.tomcat.valve.RequestTracingValve.callNextValve(RequestTracingValve.java:113) 在com.sap.js.statistics.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:59) 在com.sap.core.js.monitoring.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:27) 在org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) 在org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) 在org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) 在org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:609) 在org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) 在org.apache.coyote.AbstractProtocol $ ConnectionHandler.process(AbstractProtocol.java:810) 在org.apache.tomcat.util.net.NioEndpoint $ SocketProcessor.doRun(NioEndpoint.java:1623) 在org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) 在java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 在java.util.concurrent.ThreadPoolExecutor $ Worker.run(ThreadPoolExecutor.java:624) 在org.apache.tomcat.util.threads.TaskThread $ WrappingRunnable.run(TaskThread.java:61) 在java.lang.Thread.run(Thread.java:836)
已启用主体传播,并且SAML配置也正确。 根据我在文档中阅读的内容,这应该是所有需要完成的工作。
有人可以指出我哪里出了问题吗? 预先感谢!
(16.8 kB)
乔安娜,
我在Cloud Foundry上运行的应用程序以及在本地SAP NetWeaver Java上访问JAVA Rest服务时遇到了类似的问题。 那也是你的情况吗? 您是否正在通过SAP Cloud Connector调用本地服务?
BR,
Todor
Hi Todor,
不幸的是,我们的方案是访问Cloud Platform上托管的Java应用程序。 UI5和Java应用程序都托管在同一个neo子帐户中。
此致
Joanna
AFAIK SAP CP Neo仅支持保护Java应用程序。 我认为您不能使用基于FORM的身份验证。
您好,Gregor,
根据文档,基于FORM的身份验证将触发SAML身份验证。 我也尝试直接使用SAML2,但结果相同。 当我尝试使用BASIC时,弹出窗口将不断返回,因此似乎以任何形式进行的身份验证似乎均不起作用。
此致
Joanna
问题似乎不在应用程序层上,而是在子帐户中设置的SAML中(一旦切换到FORM,应用程序便开始使用SAML 2.0 身份提供商)。
该错误消息由SF显示,因此问题至少在SCP上不存在。 您是否已在SCP子帐户和SF之间配置了相互信任(将SCP添加为SF上的受信任服务提供商)?
最好的问候,
卢卡斯
我建议您安装 SAML Chrome面板,并尝试使用开发人员工具启用身份验证并检查您在SAML交换中看到的错误。
一周热门 更多>