SAML / SSO

[Chuck Boecking]

Hi Everyone,

Does anyone have interest and/or opinions on SAML? Please reply if you have thoughts you would like to share with the group. I believe we will move forward with this topic in the next 8 months.

The hope/vision is to create a community/core enhancement with a reference implementation that also allows you to create a vendor specific plugin.

Regards,

Chuck

www.chuckboecking.com

[Chuck Boecking]

Further thoughts on the topic:

1. I need help from the community choosing the default SAML application. Steven from Adaxa referenced an implementation with Keycloak.
   
2. When logging into iDempiere the following considerations exist:
   1. Authentication (username and password)
   2. Session detail selection (client, role, org, warehouse, date)
3. Options for login experience
   1. User authenticates in SAML app and user is presented with iDempiere session detail panel.
      
   2. User authenticates in SAML, and the SAML is configured to either ask user session questions, or SAML is configured to make session assumptions.
      
      1. In this option, the user lands directly on the iDempiere home page.
         
4. It is possible to configure multiple SAML 'apps' where each app is connected to a collection of pre configured session details.
5. I have noticed that iDempiere jumps between managing the session ID in two places (cookie and url). I do not know how to force one or the other. I also do not know how much this point relates to the SAML discussion.

Does anyone have any other thoughts or considerations?

[Carlos Antonio Ruiz Gomez]

Chuck, around 2019 I did a bit of research - not too complete - about integrating iDempiere with Apereo CAS

I cannot say if is good or not, it looks like a very mature project for SSO which supports pluggable authentication and many protocols including SAML, OAuth, OpenID.

So, is something like CAS is specialized on managing all the authentication stuff, and if you can integrate iDempiere with CAS then you basically have support for all those mechanisms.  (in theory, I never managed to test if that's true).

Now, there is a very old adempiere thread here:

https://sourceforge.net/p/adempiere/discussion/610546/thread/0590559d/#65ed

where egwada shares a file ADempiere-CAS.zip for adempiere 3.6.0

I checked that file and it seems the big change was in web.xml (adempiere 3.6.0 was jboss or tomcat, I don't remember, and now iDempiere is jetty)

The other changes described there are little: LoginWindow, RolePanel, Login

But remember also that adempiere 3.6.0 had a different login model than iDempiere.

In adempiere the login was driven by role, and in iDempiere we changed that to put client on top.

____________

On the other hand, I think you already mentioned this, the selection of tenant on the second login panel complicates a lot the integration with any SSO.

One option that we were considering is to make the tenant part of the login, something like, in the login page you can say:

Username = GardenWorld\GardenAdmin    <- the \ is just a common notation, we could define any separator - but the idea is to have tenant and user selected on the login box

That will probable make things a lot easier for SSO.

Regards,

Carlos Ruiz

El 8/6/21 a las 21:14, Chuck Boecking escribió:

[Deepak Pansheriya (Logilite.com)]

Carlos,

What I suggest is that Role selection we keep as it is but make it to work like how it remembering previous session currently. If no preference found then we can present role selection panel. Also user has always option to switch role once login.

I am also thinking use case like user login and authenticated using iDempiere login panel but internally we use SAML to authenticate. Then iDempiere can use auth token to invoke external BI dashboards.

[Heng Sin Low]

Hi Carlos,

Instead of doing that, I think it is more user friendly to move the client selection to the first login window instead, i.e user name/email > client (if > 1) > password.

Regards,

Low

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/c1e53493-bd71-a78c-a94d-bad8e499154f%40gmail.com.

[Carlos Antonio Ruiz Gómez]

> user name/email > client (if > 1) > password

But this would expose data of the tenants for people not logged in.

Or you mean client as a text box instead of a list?

Regards,

Carlos Ruiz

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/CAC%3D6jXGK4kdASj3jBmtMNaCE3QZQzjhYUk%3DkvKSJvroYqSLUPA%40mail.gmail.com.

[Heng Sin Low]

no, as a list, filter by user name or email.

I agree it is a step back security wise (but a rather minor one).

The Client/User approach is more secure but it is a step back usability wise. SSO is meant to simplify the life of users and it seems strange that to support that, we

have to make it harder for users at the same time.

To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/CAHuCORqH1k-tk1%3DfD%3DbRyymNLswgN%3Dmu95Nkvt%2B%3DpmMCD4kgwA%40mail.gmail.com.

[Carlos Antonio Ruiz Gomez]

I think disclosing the list of tenants in login is a no-go for most of cloud providers.

Also - I think there are two common practices, one is to set the tenant in the URL, something like:

https://gardenworld.idempiere.org    vs   https://system.idempiere.org   -> will define the tenant, this is hard to do for us in the application side.

The other practice is to let the user box contain the tenant.

In some applications they use commonly the \\Tenant\User notation

Like here: https://doc.zarafa.com/trunk/Administrator_Manual/tr-TR/html/_multi_tenancy_configurations.html

Or in Microsoft Active Directory they use a notation like  DOMAIN\USER

I think AD is the most used in corporations "With over 95% market share in the enterprise, Active Directory likely has more market share than any other Microsoft solution on the market"

There are also other suggestion like Amazon Cognito that suggest adding +tenant to the email:

https://medium.com/collaborne-engineering/aws-cognito-multi-tenancy-188e9bd04b71

so, that would be something like admin+ga...@gardenworld.com   vs   system...@idempiere.com

But I tend to think would be simpler to follow the established standard from Active Directory ->  DOMAIN\USER

Regards,

Carlos Ruiz

El 9/6/21 a las 7:36, Heng Sin Low escribió:

[Nicolas Micoud]

Hi,

My2cents here - maybe is not directly related, but if there is a redesign of the login process, I think it could be useful, or at least to think about it.

ATM, if you have same login/password, you can choose the tenant on the 2nd panel.

If you add the tenant on the url or on the login textfield, that won't be possible.

Some years ago, we talked about that, and an option was considered for multi tenant environnement users was to have a "master" user created in System tenant (with login/password) and "real" user at tenant level (phone, email, ....)

That would let users use the ChangeRole link to switch between tenants.
ATM, they must log out, write the password, tick choose role and click on ok button to log in another tenant.

Regards,

Nicolas