3

I'm making an authentication server that will act as an identity provider for my service. Looking at the typical SAML use case, the service provider will redirect the principal to the identity provider. In my case however, is it ok for the service provider to pass user credentials to the identity provider directly? The auth server will in turn return a SAML assertion to the application server.

Edit: Also is it a good practice to separate the application server from the authentication server? In this case, my authentication logic will be complex and I want to abstract this.

Improve this question
  • 1
    In the typical sense, the application server plays the "role" of the service provider - or is provided an identity and/or session for the end user by the service provider once it (the SP) has received the SAML assertion from the identity provider. I want to make sure you're getting the terms straight & use case. Is this how you envisioned it? – Tara Hodges Jun 10 '15 at 23:17
  • Yep that's correct. I'm implementing single sign on for my service and since this complicates my authentication logic, I'm partitioning a separate authentication server (identity provider). Now I'm trying to figure out how to link these two entities. – user2066880 Jun 10 '15 at 23:27
  • 1
    So if an unauthenticated user accesses your service (app A), ideally that user will be redirected to the authentication service (identity provider) to authenticate via the SP server. The SP receives a SAML assertion and can then communicate that identity to app A, (or if they are one in the same, can establish a user session then and there). Since you asked about the SP sending credentials, the SP should not be knowing the user's credentials at all. It just knows who the identity provider said the person was via SAML. If app B needs to get the user's identity it can follow the same process. – Tara Hodges Jun 10 '15 at 23:41
  • Gotcha makes sense. Can I ask a follow up question? In my case the IDP is only ever going to be performing authentication for users trying to access my service. Right now we keep users stored in a database and the authentication logic lives in the application server. Additionally, I'd like the login form to be in the same domain as my service. Given this, would it still be logical for the SP to receive credentials and pass it to the IDP? Or am I better off keeping the auth logic centralized? – user2066880 Jun 11 '15 at 0:41
  • 1
    It may be just my preference but if you plan on implementing a model with an abstracted identity provider, it seems reasonable that user credentials and auth logic go there and it remains centralized. But I think that it's all in your design. I suppose your one service that performs authentication today can end up being your identity provider though for other services. – Tara Hodges Jun 11 '15 at 5:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.