Hi & welcome!
Since you're looking to separate distinct access levels / roles from each other, it's important to start from the acknowledgement that people in one tier should have no access route whatsoever to services in the other tiers.
Immediately, this means that you'll need a form of separation between these tiers that cannot be overcome barring your explicit authorization. Typically, that means, you share a secret with the person that grants them the ability to access the tier the secret was designed for.
- the element allows a person to gain access to services from a certain tier (eg. devops),
- a person should not be able to find this element except through your explicit authorization (eg. a promotion),
- the element combines with Spectre to generate passwords within the tier.
To put this into practice, certainly you could incorporate [3] this "secret" at different levels, such as in the site's name or the site counter. But these places are not designed to hold secret information. In order to ensure that secret information remains secret [2], we need to employ it in a phase in the algorithm that is designed for secret data.
At present, the only outwardly exposed place in the Spectre application is the Spectre secret (when signing in), meaning that you'd use a different Spectre secret for different tiers. You could take a role-oriented approach:
- DevOps: Name:
MegaCorp
, Secret: legally specific reflection warning
- Engineering: Name:
MegaCorp
, Secret: effectively backed observer hired
- Accounting: Name:
MegaCorp
, Secret: carefully adopted stake affecting
I've also seen people take a levelled approach:
- Level A: Name:
MegaCorp
, Secret: apple loose steady earth
- Level B: Name:
MegaCorp
, Secret: bank double looking lately
- Level C: Name:
MegaCorp
, Secret: cactus modified social performer
You could also incorporate the tier name into the Full Name.
That said, what we can also do is to integrate the tier into the software. We'll create a custom branded solution for your business that your employees can install. Custom builds include a special business secret which means the public Spectre application can never be used to obtain passwords for your business. This also gives you an extra layer of protection. You can then choose to either vary the business secret by role (ship separate custom Spectre clients for different tiers), add tier selection to the user interface, or do it through the Spectre secret as suggested above.
Regardless to what you choose, the main benefit to an algorithmic approach to distributing access tokens are:
- You don't need to set up and synchronize secure storage solutions
- You don't need to back up your many access tokens & keep them current
- You don't become dependant on external actors such as a cloud service to stay online
- You can make travelling employee devices stateless, so if their device is compromised it contains no database of your business' access credentials
- You can create business continuation and disaster recovery strategies that automatically reveal tier secrets to certain individuals when others become unavailable
etc.