Suggest feasibility of SAML web single sign-on implementation for the specific requirement
We have a requirement to implement SSO using SAML authentication. PRPC application will not directly with IDP to receive SAML2.0 token. Client has their own inhouse SSO service that will facilitate handshaking between IDP and PRPC application. We are using PEGA 722, hence was wondering if we can leverage OOTB "SAML web single sign-on" feature. Please suggest if this OOTB "SAML web single sign-on" can be used in lieu of this specific requirement.
Please find below details requirement:
On a high level below systems are involved in this SSO implementatio.
1) Calling Application - there will be a link embedded to initiate the SSO call
2) SSO Service - receives http request (with relevant params) from calling application. This service sends request to another service to receive the SAML2.0 token. Then this SSO service will make a call to PRPC application and pass on the SAML2.0 token via http post request.
3)PRPC application - User should be preseneted with default dashboard view in a new window.
Question is - in the above scenario can we make use of OOTB "SAML web single sign-on" feature?
Pegasystems Inc.
IN
Pega Web SSO with SAML 2.0 is a complete solution that is SAML standard compliant. It does not expect intermediary/proxy services to manage the trust relationship with IDP.
Few queries relating to the 'inhouse SSO service' that may help to see if an alternate solution is possible to achieve this scenario
- Why do we need this additional SSO service to authenticate against to IDP ?
- When it is said "that will facilitate handshaking between IDP and PRPC application", does it handle only initial handshake and handover further communication between PRPC and IDP ?
- Is it going to act as a proxy or does some validation by itself ?
CIBC
CA
Here are responses:
1) This is bank's existing solution. This "SSO Service" receives logon information request from calling app, with those info it sends request to another service that generates SAML token and send it back to the "SSO Service".
2) What I meant is - as "SSO Service" receives SAML token it post a http post request to PRPC application to pass the token.
3) No this "SSO Service" doesn't perform any kind of validation, it will simply post a http request to PRPC to pass the SAML token.
Pegasystems
I wanted to understand the need of using an intermediary to intercept the requests and then pass token to OOTB pega implementation.
I am assuming that the intermediary a.k.a the proxy would act as an identity provider and pega’s implementation should be agnostic whether the endpoint it is accessing is a Identity provider or a proxy.
So why doesn’t the customer use the IDP endpoints directly after exchanging SAML metadata.
So the crux is if the proxy is able to forward requests on pega behalf, show the login screen and forward the SAML token , the SSO should work.It entirely depends on the intermediaries implementation