SSO development with Azure and ADFS via Oauth2/OpenID-Connect or SAML2 or both

Hi all,

I’m new to this project, but my organization is not. I just learned today that we’re going to be setting up another instance of DHIS2 in Harare, and we need to do SSO if we’re going to have people logging in with their organizational account.

I have some knowledge in this area, and am probably pretty well equipped to help, if somebody wants to point me in the general direction of the authentication architecture.

FWIW, using LDAP binds to log in is not an option. It’s forbidden, because anybody involved in the implementation can either sniff or dump the password traffic. It’s incredibly dangerous to use LDAP authentication in an organization of more than a few people.

cheers,

-mark

1 Like

It looks like there’s already something in there that Lars Helge Øverland has been working on.

1 Like

Awesome @markjaroski! Glad to know you were willing to work with us on this :innocent:

1 Like

@Lars, do you actually need help? It looks like you’ve been active with this in the last month or so.

1 Like

More importantly, am I looking at the right code in the right place? Does DHIS have a concept of authentication modules? It seems that the LDAP stuff is in subclasses from Spring, not from DHIS, so right now I’m not so hopeful.

1 Like

Hey all, I’m still looking for a little guidance into the architecture for new authentication methods. Hand-holding should be minimal. I have about 25 years in Java, and 20 years in various types of SSO. Where I need help is the DHIS codebase.

1 Like

If you’re using the ldaps protocol isn’t that data passed over ssl?

2 Likes

Yes, but that’s not the point.

LDAP is a protocol for verifying credentials against an x509 credential database. That means the site you authenticate to has to ask for a username and password. Obviously it’s better to then pass that credential over transport layer security, or in older terms SSL. But you still have to hand over your credential, and that should scare you.

SSO is an arrangement in which you can authenticate once with a given website (an Identity Provider) which then vouches for you with other websites (the Resource Providers). There’s some relationship established in advance between the IDP and the RPs which makes this possible.

The RPs never ever under any circumstances see or even need your credentials. That’s good because the fewer parties that have to know or be able to recognize a credential the more secret it is, and the idea is that these things should be and stay secret.

1 Like