Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?

I am aware that this is not the usual way for SAML to work.

The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.

Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.

The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.

1

1 Answer

Question 1: Is there a possibility to verify login+password in Perl via SAML at an Identity Provider (IdP)? If yes: how?

Answer:
Definitely No, from the cybersecurity perspective.

Question 2: I am aware that this is not the usual way for SAML to work.

Answer:
Yes. You are correct.
(I) The SAML specification defines three roles: a user, an identity provider (IdP), and a service provider (SP). In the primary use case addressed by SAML, a user requests to access a service or log in to a web application from a 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 for the user, that is, it can decide whether to allow the user to access the service or log in to a web application.

(II) Before delivering the subject-based assertion to the SP, the IdP may request some information from the user (such as a user name and password) in order to authenticate the user. SAML specifies the content of the assertion that is passed from the IdP to the SP.

(II.a) In SAML, one identity provider may provide SAML assertions to many SPs.

(II.b) Similarly, one SP may rely on and trust assertions from many IdPs. This will be the SAML scenario of your web application if your product manager decided to request all 4 different clients of your web application to develop their own SAML IdP. For example, some social websites allow their users to log in to their web account through identity authentication provided by the third-party IdPs such as Google, Facebook, LinkedIn via OAuth 2 protocol or OpenID Connect protocol/OAuth 2 (instead of SAML).

Question 3: The background to this is that we have 4 different clients for our web application, which is supposed to enable a central password via SAML, which are implemented in completely different technologies.

Answer:
If 4 different clients for your web application are supposed to enable a central password via SAML, they can implement their own SAML IdP in completely different technologies or programming language such as Java, PHP, or Scala.

(I) For example, We developed our former version of Zero-Password Authentication and Authorization System in Java and leveraged Java-based Shibboleth IdP to provide SAML SSO for enterprise applications.

We developed our current version of Zero-Password Authentication and Authorization System with scalability and high availability in Scala to provide SAML SSO natively for enterprise applications without Shibboleth IdP.

(II) No matter which technology or programming language are used by 4 different clients of your web application to implement their own SAML IdP, their SAML IdP only needs to authenticate their users using a central password data store/repository (such as OpenLDAP or MySQL) locally and then deliver the user info using SAML assertion/SAML response to your web application/SAML service provider. Your web application/SAML service provider just needs to map the user info carried by SAML assertion to a local user info of your web application.

Question 4: Our product manager has decided that a SAML connection is too complex for the 4 clients and that authentication should therefore take place centrally in the web application.

Answer:
If the user identity authentication needs to take place centrally in your web application instead of in the SAML IdP, then 4 different clients do NOT need to implement their own SAML IdP from the cybersecurity perspective.
Instead you just need to create and assign different sub-domain to all 4 different clients, that is, all 4 different clients of your web application access different sub-domain, such as client-org1.your-web-app.com, client-org2.your-web-app.com, client-org3.your-web-app.com, client-org4.your-web-app.com.

Note that different sub-domain of your web application displays the same login webpage. Example #1: client-org1.box.com, client-org2.box.com if your clients also subscribe Box account, or Example #2: client-org1.my.salesforce.com, client-org2.my.salesforce.com if your clients also subscribe Salesforce account.

Question 5: The clients transfer login and password to the web application, just like without SSO, and the web application is supposed to verify the access data centrally.

Answer:
Different sub-domain of your web application displays the same login webpage. 4 different clients of your web application access different sub-domain of your web application, users of 4 different clients submit their login and password to your web application (through different sub-domain URL), just like without SSO, and the data store/repository of your web application is supposed to verify the access data (i.e., login username/password) centrally. Then 4 different clients of your web application do NOT need any SAML IdP.

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.