I am developing a Web API that talks to Azure AD Graph to get and update user and group information. So I have implemented a service application/service principal according to the article at https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet, using Windows PowerShell.
I now want to add some custom attributes to my application so that groups can have extra fields. However I can only see it in the Azure Portal when I refer to it by its specific application id and also I can't get to it using the AD Graph RESTful API at https://graph.windows.net/{mytenant}.onmicrosoft.com/applications or /{mytenant}.onmicrosoft.com/applications/{objectId}/extensionProperties and thus can't add any new custom attributes by using the corresponding POST endpoint.
Comparing my service application with other enterprise applications in my tenant, it also doesn't have a publisher showing in the enterprise applications blade.
Please can anyone advise whether this is supposed to work, and if so what am I missing by way of configuration?
thanks
Simon
The issue you are seeing here is due to the fact that the tutorial you followed had you create a Service Principal using AAD PowerShell, however the properties you are looking for are on the Application Object.
You can read more about the differences here.
Application object
An Azure AD application is defined by its one and only application
object, which resides in the Azure AD tenant where the application was
registered, known as the application's "home" tenant. The application
object provides identity-related information for an application, and
is the template from which its corresponding service principal
object(s) are derived for use at run-time.
Consider the application object as the global representation of your
application (for use across all tenants), and the service principal as
the local representation (for use in a specific tenant). The Azure AD
Graph Application entity defines the schema for an application object.
An application object therefore has a 1:1 relationship with the
software application, and a 1:n relationship with its corresponding n
service principal object(s).
Service principal object
The service principal object defines the policy and permissions for an
application, providing the basis for a security principal to represent
the application when accessing resources at run-time. The Azure AD
Graph ServicePrincipal entity defines the schema for a service
principal object.
Before an Azure AD tenant will allow an application to access the
resources it is securing, a service principal must be created in the
given tenant. The service principal provides the basis for Azure AD to
secure the application's access to resources owned by users from that
tenant. A single-tenant application will have only one service
principal (in its home tenant). A multi-tenant Web application will
also have a service principal in each tenant where an administrator or
user(s) from that tenant have given consent, allowing it to access
their resources. Following consent, the service principal object will
be consulted for future authorization requests.
My suggestion is to use the Graph API/Portal UX/PowerShell to create an Application Object first, and then follow the tutorial by updating the service principal of the application you created.
Let me know if this helps!
Related
Background:
I have 2 services, A and B, both requiring access to service X, all running on Cloud Run.
Service X requires authentication, since both A and B have their own service accounts, I gave them the invoker role on service X, made sure access tokens are set on headers, so everything works.
Actual question:
I want to restrict access to specific APIs within service X. Ex: I want Service A to be able to only use READ endpoints, but B to be able to also use WRITE endpoints.
Is there any way to include custom scopes or claims to access tokens generated by GCP from service accounts so I can have granular access control at the API level?
Note: I come from an Azure background, where we could setup and API with scopes, and assign those scopes to accounts. Trying to understand if there's an equivalent on GCP.
In gcp we can create a custom role service account while calling API, In your case you need to create 2 service account with custom role, one with viewer role and other with writer or editor role.
Here is a blog explaining the process of creating a service account with custom roles.
While calling an API make sure you are using the correct service accounts for performing read and write operations respectively.
I am developing a python app running on embedded linux to access office365 calendar via the EWS interface. I plan on using impersonation to access data.
I have registered my app with azure AD and retrieved the endpoints which contain a tenant id. But I have learned that using the common endpoint seems to work just fine in refreshing the access token.
what are the advantages or limitations in using the tenant id instead of just using common?
Take a look at http://www.cloudidentity.com/blog/2014/08/26/the-common-endpoint-walks-like-a-tenant-talks-like-a-tenant-but-is-not-a-tenant/. The common endpoint does late binding to the tenant based on the users login details. The article does add "For line of business applications you do NOT want to late bind the tenant, in fact you want to ensure that the caller comes from your specific tenant and no other! In that case, use of common is not appropriate."
I have simple ASP.NET MVC survey generator, that based on the URL displays various forms and persists data input from user:
http://survey.mydomain.com/ConferenceFeedback
http://survey.mydomain.com/DailyReport
etc.
Some of these subapps should be accessible by everyone, some by specific set of users. My user store is Azure AD. Is there is any Azure AD related feature that is a good match for my authorization scenario, where I could assign user rights on Azure side and just validate some claims or roles in my app per user request?
You might want to look into application roles. You can define roles representing the various subapps you want to model, and you can assign users to them accordingly. On the application side, you can examine the incoming claims set and decide whether the user has the necessary role claims for accessing the portion of the app they are requesting. See https://github.com/Azure-Samples/active-directory-dotnet-webapp-roleclaims for a sample app demonstrating the approach.
I'm developing an application for my company's internal use. We wish the application to live on Azure and to utilize windows accounts for authentication. We are working on enabling Active Directory Federation Servers (ADFS) in order to synchronize our organizational AD to Azure AD. While that is being done, I am working on code responsible for determining who a user is. My main goal is to restrict the Admin controller to those users who belong to an active directory group. My impression is that ADFS should allow me to query this in Azure.
I have created a service that utilizes LDAP to determine whether or not the current user is in a particular group, and it works great locally. However, through some reading, I've determined that LDAP is not supported by Azure AD. Darn!
The preferred route to communicate with the Azure AD seems to be the Graph API. However, the graph API does not seem to be support by an enterprise/organizational AD.
My first thought solve this is to utilize dependency inject to switch the service being used based on the environment, but I'm thinking there has to be a better way.
What technology should I be using to interact with both on-premise Active Directory, as well as Azure Active Directory?
We faced this same issue in our Azure implementation and discussed it at length with Microsoft. Currently there is no common method for directory queries. I believe Microsoft's plan is to eventually add GraphAPI to AD DS.
Another option, if you're using a claims-based authentication protocol like OpenID Connect, is to have the Identity Provider issue claims with the values needed for your authorization logic.
ADFS is a tool for identity federation and not directory sync. For directory sync you would use AADSync - http://www.microsoft.com/en-us/download/details.aspx?id=44225
The simplest way to achieve this is to use federation with ADFS and have ADFS populate the assertion with Role information. Set up a new relying party in ADFS and add the a new Issuance Transform Rule
Template: Send Group Membership as a claim
Name: Admin claim
Users Group: Choose your domain local group
Outgoing claim type: Role
Value: MyAdminRole
You can set up the federation very easily with Visual Studio 2012 or later or add an OWIN startup class such as the following:
public void ConfigureAuth(IAppBuilder app)
{
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
app.UseWsFederationAuthentication(new WsFederationAuthenticationOptions()
{
MetadataAddress = "https://adfs.domain.com/federationmetadata/2007-06/federationmetadata.xml",
Wtrealm = "urn:appid"
// SignInAsAuthenticationType = // This is picked up automatically from the default set above
});
AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
}
Then all you need to do is add the Authorise attribute to your controllers:
[Authorize(Roles = "MyAdminRole")]
public class AdminController : Controller
{
...
}
For completeness, I will also add that once AADSync is configured and running, you can also use Graph API to obtain information about your users once it has been synced to Azure AD. User and Group updates can be delayed by upto 3 hours though.
HTH
I setup and MVC 4 application and added authentication against our Azure AD server as outlined here: http://msdn.microsoft.com/en-us/library/windowsazure/dn151790.aspx
Authentication works as expected. However, I'm not getting any roles back by default. There should be several AD groups created and I would like to use them to role restrict the application via the [Authorize] attribute in MVC.
I can't really find a good place to even start figuring this out. Can anyone give me an outline or point me to a good tutorial?
I should mention that I'm not the administrator for our Azure account, so I need to be able to tell our admin what to do if any setup is required on that side.
First, tokens returned by Azure AD do not currently contain claims for roles or groups, so you need to get them from the Graph API. Second, roles in Azure AD that are returned by the Graph API are not necessarily intended for use in an ISV/LoB app, and in general you should use security groups for authorization instead. To perform authorization, you should use the checkMemberGroups or getMemberGroups operations in the Graph API, which are transitive and valid for this purpose.
If you check out the following resources in order, I think your questions will be answered. You'll learn how to authenticate to the Graph, call it, and configure your application to use the result of the group operations to perform authorization:
Using the Graph API to Query Windows Azure AD -- This is the second walkthrough to complete now that you've done the web SSO one.
Authorization with Windows Azure Active Directory
MVC Sample App for Azure AD Graph
Blog post describing checkMemberGroups and getMemberGroups
How do I get role and group membership claims for users signing in via Windows Azure AD? -- This one is out of date in regards to the methodology for authentication and the UI for managing users/groups, but it's still useful. Pay special attention to the section on the custom ClaimsAuthenticationManager, which gives you an idea of how to inject role/group data into the ClaimsPrincipal object early so that it can be used in the [Authorize] attribute or other authorization logic.
Sean answer is a bit outdated. You can now configure Azure AD so it will include groups or roles inside JWT token so it will be included into ClaimsPrincipal.Current.Claims so standard [Authorize(Roles = "yourRoleName")] attribute will work.
Here is introduction post. Which basically says you have two options:
Use groups claim - you need to change groupMembershipClaims value in app manifest and later in application you can check for ClaimsPrincipal.Current.FindFirst("groups").Value to see in what group user is (you only get group id). You can write you own Authorize attribute that use this. more info
Define roles for you application and then use normal code for testing if user is in role:
[PrincipalPermission(SecurityAction.Demand, Role = “yourRoleName”)]
[Authorize(Roles = “yourRoleName”)]
if (ClaimsPrincipal.Current.IsInRole(“yourRoleName”)) { //do something }
You need to edit roles in you app's manifest.
More info here and here. Values needed to be set in manifest are described here
What is really strange is that you can't assign more than one role to group from Azure web page. You need to use azure graph api for this.
If you can't see Users and Groups tab in Azure portal you probably need Azure AD Basic or Premium edition. If you are working on free azure subscription you can use free Azure AD Premium trial to test stuff.