The problem is actually a bit more general than just passwords alone, it's any kind of secret credential like keys, tokens, and certificates that enables authority. Thus the problem is actually about authority management.
Even when SSO is involved, there's always going to be credentials that enable access to various external systems. Especially when autonomous services or apps need to perform actions. Also SSO is very much human-operator centric, and is only suited for tightly-managed centralized systems. Such kinds of centralization is ripe for service downtime if the SSO gateway/portal ever goes down, especially if somehow you hacked the SSO flow into autonomous systems. It becomes a single point of failure.
> What are the recommended ways to store and give access to passwords?
If it's just passwords alone, using a cloud password manager is probably fine.
> How can a new hire be given access to all required passwords day 1?
Although you can just select a bunch of passwords in your favorite cloud password manager and share them with the new employee account, the challenge is actually scoping their authority, tracking them, and managing change, entropy and sprawl - that's not well managed by password managers yet, because password managers are primarily just the key-value DB CRUD of passwords, they have no awareness of the Source, User and Target of authority. So this is what we are focusing on in Polykey.
> And when such new hire gets promoted, how can we give access to the additional passwords they will need?
See previous answer. This requires understanding authority scope, which is best done with some sort of visualisation system.
> And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?
See previous answer. This requires automation that integrates with the source of authority and other users of authority. It's a also a deployment problem tying into devops and so on. The key thing to understand is that once you share a secret with them, there's no takebacks. Capability-based security theory does mention ways of dealing with this, such as delegating a proxy derivative authority rather than the true underlying authority.
We're still in development and we're currently working on the enterprise portal as a control plane for addressing the more difficult questions you have. We've got internal documents explaining the theory behind the general problem of authority management, however they haven't been released to the public yet. I will likely publish them on our https://polykey.com/docs soon.
The problem is actually a bit more general than just passwords alone, it's any kind of secret credential like keys, tokens, and certificates that enables authority. Thus the problem is actually about authority management.
Even when SSO is involved, there's always going to be credentials that enable access to various external systems. Especially when autonomous services or apps need to perform actions. Also SSO is very much human-operator centric, and is only suited for tightly-managed centralized systems. Such kinds of centralization is ripe for service downtime if the SSO gateway/portal ever goes down, especially if somehow you hacked the SSO flow into autonomous systems. It becomes a single point of failure.
> What are the recommended ways to store and give access to passwords?
If it's just passwords alone, using a cloud password manager is probably fine.
> How can a new hire be given access to all required passwords day 1?
Although you can just select a bunch of passwords in your favorite cloud password manager and share them with the new employee account, the challenge is actually scoping their authority, tracking them, and managing change, entropy and sprawl - that's not well managed by password managers yet, because password managers are primarily just the key-value DB CRUD of passwords, they have no awareness of the Source, User and Target of authority. So this is what we are focusing on in Polykey.
> And when such new hire gets promoted, how can we give access to the additional passwords they will need?
See previous answer. This requires understanding authority scope, which is best done with some sort of visualisation system.
> And if someone leaves the company, how can we change only the sensible passwords they had access to and preferably notify everyone with access to it that it was changed?
See previous answer. This requires automation that integrates with the source of authority and other users of authority. It's a also a deployment problem tying into devops and so on. The key thing to understand is that once you share a secret with them, there's no takebacks. Capability-based security theory does mention ways of dealing with this, such as delegating a proxy derivative authority rather than the true underlying authority.
We're still in development and we're currently working on the enterprise portal as a control plane for addressing the more difficult questions you have. We've got internal documents explaining the theory behind the general problem of authority management, however they haven't been released to the public yet. I will likely publish them on our https://polykey.com/docs soon.