Proxy on top of OIDC IdP provider to accept SAML requests from service provider for SSO
up vote
0
down vote
favorite
Context:
We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.
Idea:
Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.
Questions:
I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:
- Does this approach even make any sense?
- What would be the security implications of this approach?
- Are there other simpler/better solution to it or a similar use case?
Any sort of help will be highly appreciated.
Thanks!
single-sign-on saml oidc idp
asked Nov 9 at 14:43
bikashp
193312
add a comment |
up vote
0
down vote
favorite
Context:
We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.
Idea:
Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.
Questions:
I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:
- Does this approach even make any sense?
- What would be the security implications of this approach?
- Are there other simpler/better solution to it or a similar use case?
Any sort of help will be highly appreciated.
Thanks!
single-sign-on saml oidc idp
asked Nov 9 at 14:43
bikashp
193312
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Context:
We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.
Idea:
Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.
Questions:
I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:
- Does this approach even make any sense?
- What would be the security implications of this approach?
- Are there other simpler/better solution to it or a similar use case?
Any sort of help will be highly appreciated.
Thanks!
single-sign-on saml oidc idp
asked Nov 9 at 14:43
bikashp
193312
Context:
We have an OIDC IdP that we don't have control over but we need to support SAML requests from Service Provider (SP) for SSO.
Idea:
Build a proxy (an app) that sits between SP and OIDC Identity Provider. Requests from SP are sent to the proxy app (that acts as SAML IdP for SP) and the proxy app converts the requests to OIDC requests and forwards them to OIDC provider. The results from OIDC provider are returned to the proxy app which translates them into SAML responses and forwards them to SP.
Questions:
I've very limited knowledge on SAML IdP (implementation wise). The approach seems very hackish to me :) Feels there are a lot of things I'm missing to consider. So, wanted some help and guidance as for where I'm doing things wrong. Few things I wanted to ask are:
- Does this approach even make any sense?
- What would be the security implications of this approach?
- Are there other simpler/better solution to it or a similar use case?
Any sort of help will be highly appreciated.
Thanks!
single-sign-on saml oidc idp
single-sign-on saml oidc idp
asked Nov 9 at 14:43
bikashp
193312
asked Nov 9 at 14:43
bikashp
193312
asked Nov 9 at 14:43
bikashp
193312
asked Nov 9 at 14:43
bikashp
193312
asked Nov 9 at 14:43
bikashp
193312
193312
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.
As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.
If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.
Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.
Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.
As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.
In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.
answered Nov 10 at 16:43
codebrane
1,4261914
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.
As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.
If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.
Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.
Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.
As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.
In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.
answered Nov 10 at 16:43
codebrane
1,4261914
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
add a comment |
up vote
1
down vote
accepted
It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.
As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.
If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.
Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.
Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.
As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.
In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.
answered Nov 10 at 16:43
codebrane
1,4261914
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.
As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.
If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.
Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.
Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.
As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.
In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.
answered Nov 10 at 16:43
codebrane
1,4261914
It's becoming a pretty common problem to have as more services move to OpenIdConnect e.g. a SAML workflow running in parallel with Office365 OIDC authentication. Your approach makes perfect sense.
As you say, the IdP should translate the OIDC JWT claims to SAML attributes for the SP to consume and there are various options for bridging between SAML and OIDC.
If you want to go the paid route, Overt have a Shibboleth/ADFS bridge with a cloud based IdP.
Or your could install the 'standard' IdP and develop your own bridge. Basically it would delegate authentication to the OIDC provider and turn the claims to SAML, perhaps augmented with an LDAP lookup to get more attributes.
Or you could use the 'standard' IdP and install apache and mod_auth_openidc in front of it to manage the OIDC authentication and claims handling.
As for security, as long as you can trust the OIDC claims you should be fine. The SAML trust has already been taken care of by the SAML metadata of the IdP/SP. The authentication will be handled by OIDC and JWT claims will be sent to your SAML IdP so as long as you secure the route between IdP and OIDC it should be as secure as the SAML route.
In the case of Office365 as the OIDC provider, the IdP will need to be registered as a tenant app and the claims will be sent to its replyUrl.
answered Nov 10 at 16:43
codebrane
1,4261914
answered Nov 10 at 16:43
codebrane
1,4261914
answered Nov 10 at 16:43
codebrane
1,4261914
answered Nov 10 at 16:43
codebrane
1,4261914
1,4261914
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
add a comment |
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
Thanks, @codebrane. This is really helpful.
– bikashp
Nov 13 at 11:40
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53227919%2fproxy-on-top-of-oidc-idp-provider-to-accept-saml-requests-from-service-provider%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
