Reading through this : https://www.rfc-editor.org/rfc/rfc6749#section-3.3 trying to understand scopes. According to the spec, scopes are defined in the auth server but need not to be tied to a single application(I am inferring). When I work with Azure, custom scopes seems to be tied to an app registration (My API ). Is this the case or am I missing something? Is there a way to define scopes that isn't tied to an App (or more than one app).
For example, Directory.Read.All scope, I can imagine more than one API hosted behind a resource server implement all Directory services in graph (not one?)
scope is a vague concept to me so my apologies if my question doesn't make sense.
When I work with Azure, custom scopes seems to be tied to an app
registration (My API ). Is this the case or am I missing something? Is
there a way to define scopes that isn't tied to an App (or more than
one app).
When you get the token, you must specify the scope value. Just like you think, your custom scope is actually that you expose the application protected by Azure. Usually it is used as a back-end application. When you use the front-end application to access it, you must specify the scope of the back-end application. It is usually: api://{back-end app client api}/scope name
Directory.Read.All scope, I can imagine more than one API hosted
behind a resource server implement all Directory services in graph
(not one?)
No, it's not like you think. You should put the api you want to access in the scope. For example, if you want to access MS graph api, you can put https://graph.microsoft.com/.default. If you want to access a custom api, you can put in api://{back-end app client api}/scope name.
The access token is issued according to the api audience you want to access, it is unique! see: here.
Related
I understand that App Registration represents an app that might have UI for users to login.
I understand that a Service Principal is for applications like scheduled batch processing applications.
But from the technical perspective, in Azure Portal App Registration list, I can see both of them in the list and look the same.
Is there anything that an SP can do that an App Registration cannot or vice versa?
It is very confusing! And unfortunately the link juunas pointed to is not only confusing, it contains bad information! To further demonstrate how confusing it is, answers you have received here are also not exactly correct! It's a real mess, and Microsoft is not doing a great job bringing clarity to the subject.
AlfredoRevilla got really close. Unfortunately, he pointed to the same bad documentation as well, which does not add much clarity to the subject.
To start, an Enterprise Application is not a service principal. This can be easily demonstrated by creating a SP using CLI (az ad sp create). After creating a Service Principal this way, you will see the corresponding App Registration...but no "Enterprise Application" will appear. Again, to make things confusing, Microsoft decided to tack-on the ability to view Service Principals not associated with an application object in the Enterprise Apps blade. This is done by using the drop-down to display the misnomered "Application Types" (not to digress too much here, but "Application Type == Managed Identity" is a clear example of how poorly this drop-down is named). More on this later.
So, to your question. Yes! There is something App Registrations can do that SP's can't do, and vice versa. They are actually different object types, just object types that look and seem to be used the same (now that isn't confusing at all, is it??? Way to go Microsoft.)
Unfortunately, I'm going to end up giving an answer that also is not quite satisfying from a technical perspective. I do this only in attempt to make some sort of sensical answer to a very confusing situation...and to avoid digressing into things like multitenancy applications and redirect URLs.
A Service Principal is the identity object in Azure Active Directory that allows roles to be assigned to various objects (resources). Thus the SP can be assigned as a Storage Blob Data Reader, or as a Key Vault Secrets User. Notice how I intentionally avoided using a web API as an example there? I did that on purpose, because Microsoft only wants to talk about this subject in context of API's and applications...bringing little clarity to the subject for non-API use cases. A key concept here is that a Service Principal will be created in your AAD whenever you create an App Registration or register an existing Application object (say from the marketplace or another tenant).
Creating an App Registration is going to essentially define the application itself. It is the view into the Application object. The Registration instantiates the application, defines who can access it (single tenant/multi-tenant), and defines various elements needed for token exchange, branding elements, etc.
But what about that "Enterprise Application" thing? What is it, and why is it tightly tied to the subject of Service Principals? You will find information that mistakenly implies an Enterprise Application is exactly the same as a Service Principal / is a Service Principal. But as pointed out above, a little experimentation in Azure quickly reveals this is not quite the case. Fortunately, it is easy to sort this part out by recognizing there is no such thing as an "Enterprise Application" Azure! Seriously, they do not exist. Microsoft created a blade in the Azure Portal that they named "Enterprise Applications" -- very poor name choice. What this blade does is provide a view to the Service Principal objects in Azure (be it a Service Principal for an Application object, or a Managed Identity Service Principal). That's it! So when you see that "Enterprise Applications" blade, just think "Service Principal identities" and don't get fooled into thinking there is another piece of this puzzle to figure out.
The App registration is the template used to create the SP. The SP is a security principal (like a User) which can be authenticated and authorized. Follow juunas link, specially Relationship between application objects and service principals.
The App Registrations view shows Azure AD Applications, which are identified by its Application ID, while Enterprise Applications view displays Service Principals. You can navigate from the Application to its associated Service Principal using the link labeled with Managed application in local directory in the Application Overview.
Application and Service Principal are associated by the Application ID. Often they have the same name, but they differ in its Object ID.
Please check the mentioned documentation for the purpose of Applications and Service Principals.
I have a service in Google Cloud App engine, which is behind IAP.
It is accessible only to users within my organisation.
I need to make a few endpoints of this service accessible for all users.
Is it possible to achieve?
I have found an instruction, which says that it is possible, but it also says: The allUsers and allAuthenticatedUsers values are unsupported member types in a conditional role binding. If you specify one of these member types, the setIamPolicy operation will fail.
Which is not clear for me and a bit confusing.
A small example:
My service has an url https://google-cloud-app-engine-service.com
And I want to make only one endpoint of this service available to everyone:
https://google-cloud-app-engine-service.com/public_endpoint.
Thank you!
You can't white list URL path with IAP. The finest grain is the service. I mean, you can activate IAP on AppEngine. Then, for the service that you want you can select it, go to the info panel and add allUsers or allAuthenticatedUsers with the role IAP-secured web app user
You have several alternatives
Manage the security by yourselves and don't use IAP (which is not a good idea)
Use Cloud Endpoint in front of your AppEngine. I wrote an article on this for securing with APIKey, but you can change the security definition is you want. The problem is that you have to define all your API in the Cloud Endpoint, and you have an additional component in your stack
Use 2 services (if possible). Set one public and the other protected by IAP.
As #guillaume-blaquiere suggested in his answer, I split my app engine service by two independent services and made the first one only accessible from within my organization and the second one to everyone using IAP.
Need to expose some user info to a 3rd party web service.
So created a ServicesController using DNN WebApi with the appropriate [HttpGet] method
and marked it with [AllowAnonymous].
It's all fine, but how do I make sure the needed web service is consuming it?
All the available attributes such as [RequireHost], [ValidateAntiForgeryToken], etc.., requires it to be a part of the DNN website.
Are you asking if you want to restrict the WebAPI housed in DNN to be accessible from anything but your own client? I don't think there is any attribute available in DNN to prevent that. You'd need to implement something on your own. You could pass a secret key as one of the parameter, but again it's not that secure, but it will provide some level of protection.
You could further restrict by certain IP, but this needs to be done within your WebAPI Get method itself.
I was unable to access my Backend Instance at custom domain.
For example, I have an app and I access the Normal Instance sucessfully at:
http://www.[my_app_id].appspot.com or http://[my_app_id].appspot.com
And I have a backend config name=test and I accessed Backend Instance successfully at:
http://test.[my_app_id].appspot.com
In admin interface, the "Instances" link show the instances of Backend and Normal Instance separately. The content show is the same, but is easy to see when a request go to the Backend Instance and when go to Normal Instance.
Then I configured the wildcard "test" in Google Apps to access my Backend Instance at a custom URL:
I continue access the Normal Instance sucessfully at:
http://www.[my_domain].com or http://[my_domain].com
But request at
http://test.[my_domain].com
redicted to the Normal Instance instead of Backend Instance.
The doc's said it should work but I cann't at this moment and I need uses custom domain because my app is multitenancy.
What I do wrong?
Your backed is really supposed to be accessed by the front end, as I understand it.
So when your application front end makes a request to it's back end (e.g. via a URL), it'll work as it's all done internally.
Have you set your back end to be publicly accessible?
https://developers.google.com/appengine/docs/python/backends/overview#Public_and_Private_Backends
Backends are private by default, since they typically function as a component inside an application, rather than acting as its public face. Private backends can be accessed by application administrators, instances of the application, and by App Engine APIs and services (such as Task Queue tasks and Cron jobs) without any special configuration. Backends are not primarily intended for user-facing traffic, but you can make a backend public for testing or for interacting with an external system.
I don't know why the redirection is not working, but perhaps you should modify your question to show what problem it is you are trying to solve here and get an answer to that instead?
I have googled a bit for how I should handle security in a web service application when the application is basically the data repository for a Silverlight application, but have gotten inconclusive results.
The Silverlight application is not supposed to have its own user authentication, since it will be reachable only through a web application that the user have already authenticated to get into.
As such, I was thinking I could simply add a parameter to the SL application that is a cookie-type value, with a certain lifetime, linked to the user in the database. The SL application would then have to pass this value alongside other parameters to the web services. Since the web service is hopefully going to be a generic web service endpoint, few methods, adding an extra parameter at this level will not be a problem.
But, am I supposed to roll this system on my own? It sounds to me as this isn't exactly new features that nobody has considered before, so what are my options?
First of all use SSL for the service. Otherwise users will be able to capture all the parameters passed to the service. It's still possible to see it in case of https but it will be a little bit more difficult.
Also, consider using Message Inspector for adding custom headers to the messages which you will validate on the server. This way you will not need to add extra parameters.