francoiscollerette

I'll open a ticket for the disconnect, but since Chrome makes a lot of changes lately, might be just that.

While I understand the many plugin do work with the "grayish" theme when not connected or active, I really think that for a "security software" not knowing your are not connected is a problem and not just a "status" which is why having it in an "eye popping" color would make more sense.

While I can understand that not everyone shared my concern on that, maybe just being able to "configure" de color when disconnected might be a better thing to consider.

Well I was thinking of Microsoft, but you do have to "select" the user but gives your the current user as a choice.

I was wrong on that BUT, it does POPUP a message to ask for it and not hide it until the user finally notices it.

a "welcome page" might be the solution .. something like :

"Hey you lucky guys ! IT has just installed this great software for you to use, please click here for your first login"

Also, I do think the my point the the plugin disconnect being "gray" is really hard for a user to notice.

That might be a quick win for all and requires little to no reconfiguration.

Also, and this might a be a support question, the "Force token public IP validation" is already ticked off.

But I'm still being kicked out of the plugin regularly.

Hello,

Unfortunately, I don't think it is as easy as it looks like. Do you have some examples of application doing it even for the first login ? I could have a look to their flow and see how we could improve ours. We have users supporting many authentication type so it could be hard to know what authentication should be used. We cannot really assume that Azure will work for that user. Of course, if you only have Azure as authentication method, we could assume that you want to use that authentication type, but even in those cases, we have to handle how we log out and reconnect with a different user. There is many cases to handle and I don't think there is an easy solution unfortunately. But the good news is user should not have to log in again after their first login.

Best regards,

Good ! Thanks for the pointer on the "Force token public IP validation", that will surely help in a few cases.

As for the first part, it seems really easy.

Most site, leveraging true SSO, don't need you to enter your credentials, it simply tries the "current windows user" and if then it fails, it asks for a formal login.

SITE -> AUTH ? SURE LET'S TRY THE CURRENT USER (logged in OS user context) FIRST -> GREAT IT WORKS -> YOU GET ACCES

SITE -> AUTH ? SURE LET'S TRY THE CURRENT USER (logged in OS user context) FIRST -> NAH IT FAILED -> LET'S ASK THE USER WHO HE REALLY IS

If website can do this, I really don't see why a browser plugin couldn't.

BROWSER OPEN -> PLUGIN LOADED -> HEY I NEED TO GET AUTH AND I ALREADY HAVE THE SERVER CONFIGURATIONS -> LET'S TRY WITH THE CURRENT USER (logged in OS user context) FIRST -> GREAT IT WORKS -> YOU GET ACCES

It's always simpler said then done, but I don't think it's that far fetch neither technically complicated.

Just like every software open in the user context, with SSO, you can reuse the existing valid auth token.

Well in a business with 450 persons, our users don't "install" the plugin themselves.

Giving users the opportunity to install "unapproved plugins" would quite a problem security wise.

It's actually pushed by GPO/Config Policies with pre-config settings.

And thus, the plugin is never "connected" unless the user manually goes in it to login.

That the reality we have bought DVLS for as an "enterprise wide password vault" and not only an IT/privilege/PAM password vault scope.

That is why I'm focusing on a "no interaction" approach, clearer things like a "RED" vs "GRAY" plugin so it instantaneously pop to your eyes.

Us, IT people, are used to those circumstances but not the regular "end users".

I think I understand why we are not understanding each other. You're looking at it as a power/admin/rdm user.

I'm bring the "regular user" point of view. (let's say an accounting clerk)

Most "regular" users, if not pretty much all, will never user the "web interface" of DVLS. At least not in a day-to-day basis.

They will only use the Chrome/Edge/other Browser plugin for automatic password vaulting.

As an admin myself, double/triple login is quite common .. I couldn't count the number of times I login with my creds in a single day but that's not the reality of a regular user.

Their reality is, they open up their browser, go to a site and .. it has to work .. if not you get a ticket or yelled at (that never happens of course) depending on the user.

That's why I'm putting so much focus on the SSO/seamless login part of the internet browser plugin.

The more users have to think about something, the more clicks they have to make, the less they will use the product or conform to your security measures.

So having to notice my plugin is GRAY, lost with other gray icons, having to click on it and then select "connect" and then selecting an authentication method (not anymore :-) ) is a road block that interferes with the users adhesion to the product.

Now a user doesn't have to select a authentication method, great !

But it still requires a manual process and thus I think the "skip" part of it is not quite complete yet.

My bad, looks like while the browser plugin has not been updated, the modification to the server part did do the trick for it as well.

Great .

One thing stills bugs me a little.

Is there a good reason why users need to click on the "connect" button in the browser plugin ?

I would have thought that an SSO way of thinking would be to try the "current user" right out of the box.

A good example is pretty much any Office/Microsoft app/web.

It automatically tries the "current logged in user" as an SSO measure and ask to choose if multiple or fails.

Currently, the DVLS plugin seems to just stay put in a disconnected mode (gray).

Let's be honest here, a "GRAY" button is nothing a user will notice, espeacially with other gray icons just beside it.

I would rather have it "RED" so user notices that the vault is not connected instead of being frustrated it doesn't work and stops/never uses it

Again, I'm applyting a "user adoption" way of thinking.

It would also apply in the user/pass forms with the plugin icon beeing "gray"

I can see users being frustrated that their password vault is not working and just starts abandonning the use of it and reverting to bad behaviors.

While the gray/red/blue plugin is not related "per say", the fact that the plugin does not "auto authenticate" and is hard to noticed that something went wrong during the authentication of the plugin ... seems related after all.

That's great that is *should* finally be incoporated in DVLS, but is the "Chome/Edge/etc.." module been updted has well ?

If the servers can do it, the "helper" apps will have to do it also.

Considering our users is using credential injection, they rarely go on the full web site of the vault.

Several month would be unacceptable.

This has been pushed back for several months since 2020.

Great !

What kind of ETA should we expect ?

"The absense being able to save users having to manually click an option every time they login does have a rather significant impact on user experience"

I would actually rephrase this and say "it has a rather significant impact on user ADOPTION".

Even the best security practices are worth nothing if there is no user adoption.

Being at the doors of 2024, I have a really hard time understanding why such a "simple" thing is not already in place.

Hi Maurice,

"if IDP quantity = 1, then try autologin"

"if autologin fails, present "devolution login"

I don't think it needs to be "over engineered" beyond that.

Point #3 est super important.

Les message d'erreur fait plus penser à un problème avec le logiciel que d'autres choses.

"Impossible d'enregistrer l'entrée: Données invalide" .. ça sonne pas "mot de passe ne réponds pas aux exigences", mais bien "j'suis crashé"

Having to ability to configure settings of DWL/DVLS through GPO (ADMX)

This would facilitate the use of tools like Intune or tradionnal GPO to manage the configuration pushed to the users instead of relying on a JSON file..

When doing our configuration, I noticed the the "devolution login" is alway there and thus for "seamless usage with our users, having only one choice, or simply login with the default IDP automatically would be great.

Hi, we were looking into the reports and we notice there was no way for us to have a report on the user vaults.

I understand the need to keep them separate and inaccessible for others, including the admins, but it would be beneficial to at least be able to report on them.

Did our users really created "complex", "recommended strength" or followed company policy passwords ?

Did our users did some "password reutilisation" in their vault ?

Did our users changed their password since X days ? (password rotation)

While the shared vaults do enables us to be sure those passwords ar OK, more and more platforms are using a "user based" (1 account per user) then and "enterprise based " (1 account for the company/group of users) authentication. The fact that we don't know if the "user" password is following the basic company requirements is sort of a blindspot which puts, potentially, data at risk. (at least from our point of view)