Context:
We are using Azure DevOps and we are starting to leverage more and more PATs in our DevOps cycles and processes. We have about 30 users and each one of them creates a bunch of them under their personal account for different use cases.
Here are some scenarios where they are used:
Self-hosted agents configuration (Windows and dockers)
API call for Microsoft Teams bots
Homemade integration with Azure DevOps and other systems
etc.
Basically, we are starting to loose a bit the control over:
What kind of PATs are created
Where are the PATs used
Which scopes defined on the PATs
As an example, we have some users that create PATs to configure agents. They will give the full access to this PAT, instead of selecting the proper scopes for it. As we know, end users don't really care about security and we are aware that we need educate our developer. However, we still want to have way to control those PATs.
Questions:
Is there a way to view in the organization level all the PATs that used?
Is it possible to remove the possibility for a specific user to create PATs and only give that feature to the admin users?
Is it possible to revoke all the PATs on the organization level?
Can you share your experience(s) and tips on how you efficiently handle PATs in your organization and more specifically on the security aspect?
Maybe this could help you to restrict the usage of the PATs
https://devblogs.microsoft.com/devops/new-policies-to-restrict-personal-access-token-scope-and-lifespan/
Is there a way to view in the organization level all the PATs that used?
Not that I know
Is it possible to remove the possibility for a specific user to create PATs and only give that feature to the admin users?
From the article, yes it is now possible for the administrator to do so
Is it possible to revoke all the PATs on the organization level?
Yes it is, see https://learn.microsoft.com/en-us/rest/api/azure/devops/tokenadministration/token%20revocations/revoke%20authorizations?view=azure-devops-rest-5.0&preserve-view=true
Related
We are building a enterprise product, and expect a lot of customers, to not have active directory of their own.
We plan to use AAD as our IAM provider.
We plan to create a master AAD for the product, and then invite users of each customer (tenant) as external users to the master AAD, using their business email id. Each set of users for a given customer, will be added to an external group for manageability.
Would this be the right approach, for supporting multi-tenanted IAM for a product hosted in Azure?
It's a pretty hard question. AAD's multi-tenancy basically requires the org to have an AAD to have proper separation etc.
But in the case of an org not having an AAD, this is one option.
One crucial thing you must not forget with this path is to turn on the option in the AAD tenant to restrict Guest user permissions. This makes it so that the invited users can't just go to portal.azure.com and get a full list of all users in the tenant. At least usually this is a desired thing when multiple clients are in the same tenant.
Other options could be:
Setting up an AAD tenant for each customer
Good separation for customers
There might be a limit how many you can create
I'm not aware of an API you could use for this (but hey Selenium works :D)
Set up your own identity provider with e.g. IdentityServer
Maximum customizability
Lot of work for you to develop and maintain
Everything would of course be easier if they just had an AAD :)
It would depend on some details of the approach you want to follow. If you are expecting for them to use their business email, then you may consider having Single Sign-On (many organizations expect not needing to duplicate accounts and you may want to delegate your customers the hassle of resetting passwords).
Also, you need to determine what kind of isolation need(do you want to have a single set of users or have a clear separation by tenant?) and the budget (AAD cost is measured on a per-user basis) you have for this? Azure AD B2C could be also an option, or as #juunas mentioned, implementing your own solution with something like IdentityServer.
I am a part of a group trying to create an Amazon Mechanical Turk Requester task. We'd like to either have a group account or have multiple accounts with access to the same project. I've been looking around and cannot find a way to do this. Is it possible to make this happen without sharing a single account?
This may not be perfect, but if you're an MTurk API customer, you can use Identity and Access Management (IAM) to have a single account (with a credit card on file) but provide multiple sets of API credentials (AWS Access Keys and Secret Keys) that you can provide to reach person/group that wants to use the account. This isn't a perfect solution because:
It is only applicable to the MTurk Application Programming Interface (API)
There aren't quotas or controls to limit spending on one person vs. another
Each account can still access each other's HITs (it isn't separate accounts)
You can learn more about IAM support in MTurk here: https://blog.mturk.com/introducing-mechanical-turk-api-support-for-iam-credentials-8f2de8cd6afb
There is not currently a way to do something similar in the Requester Website (requester.mturk.com).
Hope that helps a little.
Can I add other developers to my Nest account? I would like each member of my team to have their own Nest user account but share the same client and test devices.
Unfortunately not at this time.
The best practice with the current setup would be to create a group Nest Account for development (using a group email address, most IT departments have self-service for this) and a separate account for production (which you should do anyways)
If you would like to suggest better account management features, the best place to do so is on the Product Suggestions board in the Nest Community.
From web search it appears that to be able to manage Windows Azure services, you need an account with one of the admin roles (service administrator, co-administrator etc).
From project management point-of-view, what is a good strategy to manage accounts for your company if you have several developers working on Azure?
Examples
A simple strategy could be to have a few designated administrators (e.g. team leaders) who upload the code while other developers use Azure Emulator on their machines.
Another example would be to have a shared Azure account used by many developers (not sure about licence implications for this one!).
These are just off the top of my head and have their drawbacks. What strategies do you use?
2 Places I've worked we've done the following.
Single Common A/C
Create a common email-distribution group (myteamonazure#mycompany.com)
Register this mail address as an MSN Passport
Use it to sign up with Azure.
Pro's: Everyone on the team gets mails regarding the account.
Con's: If someone leaves the team, we need to change the account password.
Individual accounts
Let each person signup with their own account. (Mandate it must be their company email... not personal msdn passport)
Make one person the super-admin, and the rest co-admins
Pro's: If someone leaves, it's far easier to just revoke their credentials/privs
Con's: Lots more accounts to keep track of depending on the size of your team, particularly if you're company has a single Azure Account, with lots of different apps/projects hosted on it.
Personally, I prefer the second option as it's more secure/easier to revoke access to individuals.
How do large companies implement their security requirements which are centralized and used to drive things people can do (allowed to call a certain web-service, submit an order, etc.) as well as to drive UI (disable buttons, menu options, individual form fields)?
I am considering RBAC architecture: Users -> Roles, Roles -> Privileges.
Complex applications with permissions based on many individual field-account-user-role-amountThreshhold would have many, many "Roles" and managing this gets complicated as number of roles grows.
Managing all these possible options seems daunting, and my prior experience is to hard-code such logic in the application.
Ex: If (User.Roles("IsAccounting"))
{
btnEditOrder.enabled = false;
}
I am tasked with designing / implementing a security service/architecture which will be used as common authentication/authorization point for any/all applications (all .NET, but some GUI and some process-oriented).
This is not possible out of the box because of the business organization around client accounts and permission tiers based on financial amounts.
Ex: John is a User and he can View and Submit requests for account "Microsoft" and "Google".
Mike can View "Microsoft" and "Google" requests but can only Submit "Google" requests.
Number of accounts / users is large and variable.
If I follow RBAC, there will be hundreds of "Roles" to accommodate all required Rights (Privileges). This doesn't help because the end goal is to give easy to manage GUI tool so that managers can assign their direct reports to appropriate Roles.
I was thinking to implement this security piece with the following API (rough draft in pseudo-code):
UserContext securityContext = Security.GetContext(userID, userPwd);
And usage in application would be like this:
if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}
This way there would be thousands of these 'Can(params)' methods to check permissions which doesn't make it easy to either manage or use this pattern.
Any links / ideas / pointers are appreciated.
It's a .NET shop, but nothing I've seen from .NET (Membership / AzMan) will give us the granularity and delegation requirements required. ActiveDirectory / Oracle LDAP integration would be nice, but not necessary.
Old (current) system uses LDAP to authenticate users, but all authorization is done in-house and stored in classic "Users, Roles, Rights" tables.
We were having almost same requirement, where we had multiple apps inside big organization, and we had to
Secure multiple applications for authentication and authorizations
and manage all these applications from same central location, no
matter these applications are .net or non .net, GUI based or process
oriented,
running applications might be internet based or intranet based
Applications should support AD users or federated users for
authentication and authroziation
Apply lots of 'role based' or 'permission based' security or
customizations.
ex. Enable/Disable features -like Enable buttons, Disable buttons, Hide some menus, Change background color of controls, or change any .net supported properties of .net components etc.
Secure webservice or wcf service for authentication and authorization
apply role based security for multi-tenant applications via groups
and users management
Manage organization's users for multiple applications from
central location
Tracing user's actions or auditing.