3. Create COT, Identity providers and service provider instances and then create Subjects(Users)
4. In the COT level or IDP level do the mapping.
5. Import the IDP metadata
6. In PRPC create a Authentication service and in the mapping tab do the mapping of IDP attributes with PRPC attributs.
7. Save it and access prpc with sso url.
8. Provide the credentials of any subject(operator) of IDP, request goes to IDP and authenticate and redirect to the PRPC(If operator is not there in the PRPC then based on the auth service tab mappings it will create operator using Model Operator of the passed values)
I don't think you have to do any changes in web.xml.
SAML defines three roles: the principal (typically a user), the identity provider (IDP), and the service provider (SP). In the use case addressed by SAML, the principal requests a service from the service provider. The service provider requests and obtains an authentication assertion from the identity provider. On the basis of this assertion, the service provider can make an access control decision — in other words it can decide whether to perform some service for the connected principal. SAML does not specify the method of authentication at the IDP; it may require username and password, or another form of authentication, including multi-factor authentication (MFA).
1) What is meant my Identity Provider (IDP) and Service Provider (SP) - Can you please brief me about these at high level
Service Provider is the application where user is trying to login. That is your Pega Application.
IDP is the server where the user is getting authenticated. Actually whenever user hit the url , they are redirected to IDP url and once the user is authenticated they get back to the service provider URl with token.
You can actually test it by logging in to msp.pega.com in the incognito mode. Here msp.pega.com is SP and you can see that you are getting redirecting to uag.pega.com which is IDP. Once you enter the credentials there , a token is passed to SP and you get back to msp.pega.com alongwith token and your user info.
There is a SAML plugin which you can download and use F12 to trace that. you can actually see the SAML response which you are getting.
2) Do we need to update this SAML 2.0 authentication Service rule name in web.xml file as we do for LDAP like Servlet mapping in web.xml.
If you are using 8.1 , there is no need to modify web.xml for servlet mapping. It is automatically mapped. even for LDAP there is no need to modify web.xml in 8X pega version.
Please let me know if you need further information.
And I guess we will map Servlet mapping in web.xml and prweb is a war file I guess not xml file. Please correct me If I'm wrong and Also please help me to set up SSO.
Yes I meant the web.xml inside the prweb not the tomcat one.
As per my knowledge we will configure LDAP using custom authentication Service where as for SSO we will use SAML 2.0 as Authentication type.
Both can be used for SSO , to use LDAP you need to select custom type whereas SAML2.0 for SAML. These are 2 different ways of achieving SSO where IDP will handle the authentication part instead of your own database.
The idea behind Single Sign-On is that users can use an "external" set of credentials, in this case from Active Directory, to authenticate against your application.
In practice, that "external" user ultimately maps to an internal account (a generic account, like "user") that has the correct permissions.
What SAML does is actually pass session tokens around. User credentials are passed to a token, and then that token is authenticated against the "user" account.
LDAPS would skip all that token stuff and just authenticate directly against "user". This means there's no session security, users stay authenticated forever.
I think you should first understand the difference bw LDAP and SAML . Read some documents of what LDAP and SAML does before setting it up. It will help you in understanding what both does.
There are other authentications like OAuth and Kerberos. But the way of authenticating user is different. Some are tokens based, some are session token based and some are directly authenticating from their server.