How is basic authentication for an in-house application intended to be implemented using Gluu?

By: Craig Leinoff user 10 Jan 2022 at 10:36 a.m. CST

6 Responses
Craig Leinoff gravatar
In our organization, we have numerous web apps that we want to share a single backend for authentication/authorization if possible. Right now, each uses their own disparate user store. Ideally that would be Gluu. It seems pretty straightforward to implement OIDC authentication in these apps using Gluu, but the UX for this seems suboptimal. For example, let's say my company is "Acme" and one of our existing applications, "ABC", is written in Next.js. We have a login page currently with either an email/password (which connects to a SQL user database) or an OAuth LinkedIn login. I can install a Gluu server to use as Acme's identity provider, and add a "Login with Acme" button, but that means users have to be aware that there's a separate Acme account shared across all our apps. Instead, the user should, I think, ideally be able to enter their email/password and submit it directly to Gluu, and come back to ABC app if it's good. I'm not clear whether that's non-standard, or not, however. The fact that we are allowed to have customized login pages makes me think maybe the intent is that you'd simply use the Gluu-hosted page as your ABC app login page (i.e. skip the login UI within Next.js). But we could probably integrate the two by theming the Gluu login to be barebones and integrating it using an iframe. Beyond this, though, it's not clear *what* even the login form "is". Is it the OxTrust login page? Casa? Or does Gluu server have an actual end-user login form interface that is neither OxTrust nor Casa? Thanks!
Gluu 4.3 Docker 20.1012
closed

Answers

By Michael Schwartz Account Admin 10 Jan 2022 at 11:34 a.m. CST

Copy
Michael Schwartz gravatar
```Instead, the user should, I think, ideally be able to enter their email/password and submit it directly to Gluu, and come back to ABC app if it's good.``` This totally defeats the purpose of federated authentication--to not expose the password to the website. If you want to just verify the password, you are not using OpenID Connect--you can do this with OAuth (Resource Owner Password Credential Grant). But doing so will degrade your organization's security. oxTrust is the Admin website--only for Gluu Server admins (and in production, should not be Internet facing). Casa is an Internet-facing self-service portal to enable end users to manage their credentials (2FA, password, etc). It is also has an "authentication script" in oxAuth (the OpenID Provider) which provides a starting point to use many built in authentication capabilities. You really should read my book: [Securing the Perimeter](https://link.springer.com/book/10.1007/978-1-4842-2601-8)

By Craig Leinoff user 10 Jan 2022 at 12:33 p.m. CST

Copy
Craig Leinoff gravatar
Hi Michael, thanks for the reply. I think I may have been unclear -- or else I don't understand what you're saying, in which case I apologize. I'm describing a situation wherein the user submits their password to Gluu, somehow -- our application should not be involved. Gluu has a "Basic Authentication" method which is, of course, set up by default out of the box. The documentation page for this method advises, in the "Using Basic Authentication" section, to: > Open up a new browser or incognito window, try to login into your Gluu Server or perform SSO with an SP or RP. It's not clear what the sentence "try to login into your Gluu Server" means in this case. I understand that, in a scenario where I have configured Gluu as an SSO provider, a user, say, clicking a "Login with Gluu" button on my website -- assuming they do not have an active session -- will be presented with the Basic Authentication login page. I guess, having thought about it longer, that is all "Basic Authentication" is intended to do, correct? So maybe the answer to my root question is: "The login form should not appear on your website." I would guess it still could be accomplished with the iframe method I mentioned, but -- assuming I have not misunderstood your message -- it's not clear if that's otherwise a bad practice, and if it's not, what page I could actually embed using an iframe. Thanks!

By Craig Leinoff user 10 Jan 2022 at 12:52 p.m. CST

Copy
Craig Leinoff gravatar
Just wanted to add one thing. It may be that you're reading this as a user trying to enter their federated credentials into our form (i.e. a user enters his/her Facebook credentials into our form) and our application submits it, which is obviously wrong to me. Our use-case is unifying local authentication / session context across multiple local apps.

By Michael Schwartz Account Admin 10 Jan 2022 at 1:04 p.m. CST

Copy
Michael Schwartz gravatar
iframes would still allow a website to see the password. Even though they are internal apps, you still don't want them to see the password. That would increase the security surface area of your enterprise.

By Craig Leinoff user 10 Jan 2022 at 1:50 p.m. CST

Copy
Craig Leinoff gravatar
Thanks Michael. That makes sense, and I agree. We should drop that idea.

By Michael Schwartz Account Admin 11 Jan 2022 at 10:03 a.m. CST

Copy
Michael Schwartz gravatar
Added feature request [oxauth-1631](https://github.com/GluuFederation/oxAuth/issues/1631)

Post an answer