Should an Identity Provider be a separate web application than a Authentication system

Question

I'm currently writing a SAML Identity provider(Idp) to enable SSO and one of the easy ways to go about it is to use Shibboleth Identity Provider which is a ready deployable web application on it's own.

We also have an in-house authentication system that authenticates users via login screen and also has certain OAuth service implemented.

In integrating the Shibboleth Idp an easy option is to redirect the user login part during SSO to our Authentication System. And once the user is authenticated redirect him back to Shibboleth Idp which can then send a valid SAML response.

Ideally I'd like to keep the two as separate systems(Identity provider and Authentication System) for the following reasons:

1. Relatively easier to keep them separate than trying to merge our Authentication system into Shibboleth Idp. Our Authentication System and Idp uses different web frameworks(play vs spring)

2. SAML Identity Provider to me seems like a slightly separate concern than logging a user in and in the spirit of micro services, I like it separate.

I read that there are however ways to integrate Idp into Authentication system but it seems complex and ugly.

My question is this: Does it make sense to have these two as separate systems ?

The argument against keeping the two separate is that we already have Oauth in built with Authentication system. So may be it makes sense to integrate SAML Identity provider with our existing Authentication System as well than deviate from the pattern.

Answer 1

Keep them separate because then it is easier to establish that they are each secure. For example, an injection defect in one cannot then compromise the other.

An IdP should be on separate hardware which is thoroughly walled off, both network wise and physically. Even if your identities are for low stakes activities, users who reuse passwords will resent it if you are compromised.