Hi Krish,
The "Browser POST" and "Browser Artifact" SAML 2.0 profiles supported by Verify Access both require the browser to be redirected to the Identity Provider in order to authenticate. Passing browser control to the Identity Provider allows it to manage the presentation of the login page(s) and other pages (such as password change) without any dependency on the Service Provider.
It is possible to perform authentication against an "authentication service" in other ways which don't redirect the browser but these are not SAML 2.0 and are (probably) not federation. In these cases the Service Provider would be calling (probably bespoke) APIs at the "authentication service" to perform authentication (and other actions such as password change). The Service Provider would need to understand the APIs and would also have to build the entire presentation layer locally to interact with the browser. As an example, this is how our Verify Access authentication service integration with Verify SaaS works.
If I have misunderstood your use case, please provide more detail on the flow - with step by step interactions between browser, identity provider and service provider.
Jon.
------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------
Original Message:
Sent: Mon March 15, 2021 02:36 PM
From: krish krishna
Subject: SAML SSO via API call
Hello All,
We have a requirement , where the ISAM act as identity provider and application service provider initiate the SAML SSO ,but the client dont want to happend redirect to Idp logon page ( webseal page) want to initiate call the api where SAML sso should happened return saml token.
Here we want to also handle all the usecase like change password due to expire password or suspend account.
Is this possible ?
Thanks
------------------------------
krish krishna
------------------------------