Home/ Questions/Q 8200085
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T06:18:54+00:00

We have two separate products, both including web app and server. We want to

  • 0

We have two separate products, both including web app and server.

We want to implement Single Sign On for both of them, so when a user has logged into one product, he can automatically access resources in the other product belonging to him.

I have explored a little bit and find SAML is a good approach that we can take, but we are not sure how we want to proceed.

Is it a good idea to implement our own Service Provider? I have looked at Shib SP, but looks like if I want to integrate it into my products, it won’t be that easy too.

So I am just looking for some suggestions from people who have encountered a similar problem before.

Another question is what resource that I can study if I need to implement a SP using OpenSaml? Looks like there is not a lot of tutorials or examples that I can refer to.

I would also be really appreciated if anybody can just point out some big procedures or components that my own SP need to contain.

EDIT 1:

Just try to provide more details about what I want. We have two separate products. Currently we are able to externalize user database. For example, our products can be configed to connect to LDAP server or any other external user DB as long as they implement a service properly.

Now our goal is we want SSO for both of our products. One scenario is we have our own SP component(either implement or integrate) in both products. Customer may have their own IdP. With some configuration, our SP can connect to their IdP, and do authentication from there, and user doesn’t need to login twice to access both products. Of cause, we can provide an out of the box IdP if customer doesn’t have it.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The biggest difficulty with Shibboleth is that it is, effectively, a reference implementation of the SAML v2.0 specification.

    For most routine installations, though, you actually need very little of the SAML spec to enable a couple of web apps for SSO.

    But since Shibboleth implements the whole thing, with all of its capability, it can be a bear to configure.

    We did a project with Shibboleth (and it was admittedly an on the edge use case), and, for me, a SAML novice at the time, it was really a chore to get everything up and working.

    For our next stab, I looked at the SAML spec for SSO via the Web Profile. If you read it, it’s actually quite straightforward for this limited use case. And we decided that instead of using Shibboleth again, we’d write our own IdP and SP using the OpenSAML libraries.

    Could we have got Shibboleth working faster? Probably. But I don’t think we’d have the understanding of it that we do of our own. A bit of Not-Invented-Here, sure, but this stuff is confusing enough when you do understand the software and vocabulary, much less when you don’t. And SAML is chock full of new vocabulary.

    You can also consider using SimpleSAML as an IdP and writing your own SP for your web apps. SimpleSAML is in PHP, but it’s a bit more user friendly. You can just treat it as a self contained apache service.

    I will say that our SP weighs in at around 1000 lines of javadoc’d code, but it’s mostly wiring OpenSAML stuff together and some utility stuff. In truth it’s not that scary. Be prepared to really enjoy reading signed XML blobs though.

    It is frustrating that this really isn’t simpler, but it’s a bit of a chicken/egg thing regarding adoption etc.

    And if none of that suits you, you can look at OAuth2 and some of its profiles.

    • 0