3 ms·

> Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.) How i

by dpark 10y ago

> Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.) How is this more extreme or more cumbersome than deleting an admin account? For that matter, you could also just give admins a separate admin account even if they are also users. When I worked in "IT support", I had a separate admin account even though I had a user account in the same system.

taeric 10y ago
You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The argument seems to be that the logical separation is not desired. But that implies that if I were an employee of Google, I should have a specially flagged Google account. And if I were to leave, I would lose that flag. Which means it should probably not be a simple flag, anymore, but a date gated property which may go off an on several times. And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts.
- dpark 10y ago
  > You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The separate system your company's employees are tracked is is also likely not integrated with your app database's auth system. I kind of doubt that the various Postgres/MySQL/Whatever databases at Google have accounts in them for all of Google's employees who might need access. Instead they build more tooling on top of the same accounts the app uses to access the DB. Or maybe they create JIT accounts for admin functionality. As it stands today, though, most places don't use the DB auth at all really. > But that implies that if I were an employee of Google, I should have a specially flagged Google account. No. You have two accounts if you work at Google. Your personal account is not your corp account. That doesn't mean your corp account doesn't exist in the same systems as your personal account, though. > And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts. Maintaining two entirely separate auth systems does not sound less complicated to me.
  - taeric 10y ago
    I wasn't planning on really diving on this. However, two scenarios easily come to mind. Either selling a product to another company, or getting acquired. In either case, it would be nice to not have to merge two identity management systems just because corporate structure changed.
    - dpark 10y ago
      You're arguing for a separation of customer and admin accounts. These scenarios are both easier if admin and user are rolled together. If administration is tied into your corporate user system, then transferring a product means it's a pain to enable administration in the destination environment. What you're actually arguing for is keeping app auth separate from corp auth. And that's pretty reasonable, but app admin is app auth, and must move with the app. More generally, though, anyone buying your app/company will want it integrated with whatever auth they already have anyway, so you can look forward to a big user migration regardless.
      - taeric 10y ago
        Apologies, I was always arguing for a separation of corporate and customer accounts. My assertion is essentially that all administration of the application is done by corporate users, not application users. Now, it is not uncommon to actually do this in three parts. A set of users that covers administration. Often made by tools that guarantee corporate level access to these accounts. And then a separate system built on top of them that does the application. If you have truly "admin" users in the system; then yes, they should be separate from corp. And should be a flaggable part of a normal user's account. Mixing these with who can create the tables that are required for the system to run seems awkward, at best. Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no?
        dpark 10y ago
        > Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no? I don't know what this means. I don't think there's a good argument for having multiple auth systems in general, much less three. It's a lot of redundancy for little reason. It ends up complicating every app as they end up needing to support multiple systems to support both end users and administrators. I wouldn't be surprised to find that Google has a single auth system for all users, including employees, and that they've wired up their databases to honor the single auth source.

by dpark 10y ago

taeric 10y ago

You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The argument seems to be that the logical separation is not desired. But that implies that if I were an employee of Google, I should have a specially flagged Google account. And if I were to leave, I would lose that flag. Which means it should probably not be a simple flag, anymore, but a date gated property which may go off an on several times. And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts.

dpark 10y ago
> You probably already have a separate system that is regionally and logically separated from your application to control access to company resources. The separate system your company's employees are tracked is is also likely not integrated with your app database's auth system. I kind of doubt that the various Postgres/MySQL/Whatever databases at Google have accounts in them for all of Google's employees who might need access. Instead they build more tooling on top of the same accounts the app uses to access the DB. Or maybe they create JIT accounts for admin functionality. As it stands today, though, most places don't use the DB auth at all really. > But that implies that if I were an employee of Google, I should have a specially flagged Google account. No. You have two accounts if you work at Google. Your personal account is not your corp account. That doesn't mean your corp account doesn't exist in the same systems as your personal account, though. > And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts. Maintaining two entirely separate auth systems does not sound less complicated to me.
- taeric 10y ago
  I wasn't planning on really diving on this. However, two scenarios easily come to mind. Either selling a product to another company, or getting acquired. In either case, it would be nice to not have to merge two identity management systems just because corporate structure changed.
  - dpark 10y ago
    You're arguing for a separation of customer and admin accounts. These scenarios are both easier if admin and user are rolled together. If administration is tied into your corporate user system, then transferring a product means it's a pain to enable administration in the destination environment. What you're actually arguing for is keeping app auth separate from corp auth. And that's pretty reasonable, but app admin is app auth, and must move with the app. More generally, though, anyone buying your app/company will want it integrated with whatever auth they already have anyway, so you can look forward to a big user migration regardless.
    - taeric 10y ago
      Apologies, I was always arguing for a separation of corporate and customer accounts. My assertion is essentially that all administration of the application is done by corporate users, not application users. Now, it is not uncommon to actually do this in three parts. A set of users that covers administration. Often made by tools that guarantee corporate level access to these accounts. And then a separate system built on top of them that does the application. If you have truly "admin" users in the system; then yes, they should be separate from corp. And should be a flaggable part of a normal user's account. Mixing these with who can create the tables that are required for the system to run seems awkward, at best. Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no?
      - dpark 10y ago
        > Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no? I don't know what this means. I don't think there's a good argument for having multiple auth systems in general, much less three. It's a lot of redundancy for little reason. It ends up complicating every app as they end up needing to support multiple systems to support both end users and administrators. I wouldn't be surprised to find that Google has a single auth system for all users, including employees, and that they've wired up their databases to honor the single auth source.