All we want from an org is Connected App Key/Secret credentials. Is it recommended to create an AppExchange app for this? Can creating an AppExchange app allow me to create Connected App? I am required to send this information back to my server for querying Salesforce information through APIs. Currently I am requesting admin of Salesforce org to create one connected app for me.
You do not need an app exchange app, you just need to have the provide the Admin the callback url and the and the admin can create a connected app for your application. You may also need to provide more information depending on how the app will connect to salesforce (OAuth flow etc). The Admin would be able to provide the Client Key and Secret that you need
Related
I have a WPF desktop app which connects to an Azure registered app. Within that registered app I have created App roles. Then, within an Azure Enterprise App, I add a user with one of the app roles created in the app registration. However, I can't figure out how to use this app role. I can't seem to access the role from the JWT token returned during authentication nor can I seem to use the role to modify access in Azure.
How can I use the app role to modify access?
Firstly, your WPF app doesn't call any APIs (official API or you own Web API) based on your description.
And you define the app role in the app registration which represents your WPF app. We can call it client-side app although there is no service-side app here.
So in this case, the app role should exist in the id token (not access token).
You need to parse the id token in your code and find the app roles and then verify them.
There is another situation where you are actually calling some kind of API, but you did not mention it in the post.
In this case I think you want to get and verify the app role from access token. We need to define the app role in the app registration which represents the service-side app.
There again are two situations.
One is that you are calling an official API, such as the Microsoft Graph API. This situation will not allow you to set the app role on the service side because we do not have the permission to change the official Microsoft Graph app registration. You need to take advantage of app roles from id token as introduced above. But usually we don't control the permissions like this because Microsoft Graph has its own permission control method.
The second is that you are calling your own Web API hosted on Azure. We call it AAD protected Web API. In this case you need to create an app registration which represents your Web API by following Protected web API: App registration and define the app role in this app registration and assign the app role in enterprise application which is associated with this app registration.
After that you can get the app roles in access token and verify them by following Protected web API: Verify scopes and app roles.
Although I have explained all these situations, this may not solve your issue.
It looks like your situation is the first one. You can first decode your id token in https://jwt.ms to determine whether app roles exist.
I'm creating an app registration for Azure AD using my admin account (specifically for Mobile and desktop applications authentication). I intend to create an AAD Conditional Access that will be applied to the created app registration. For some reason the App Registration is not visible on the cloud app selection when I am trying to select it.
Screenshot - Conditional Access > Policy > Cloud apps or actions > Select apps
P.S. It showed on the cloud apps when I tried adding a "Web" platform on the app registration, but still CA is not applied when trying to login using the App Registration. Am I missing anything? Thanks in advance.
Screenshot - AAD - Sign-Ins
Please note that the CA policy is applied when a client calls a service. It's not applied directly to a client (public/native) application.
See the Note tip here.
Since Conditional Access policy sets the requirements for accessing a
service you are not able to apply it to a client (public/native)
application. Other words the policy is not set directly on a client
(public/native) application, but is applied when a client calls a
service. For example, a policy set on SharePoint service applies to
the clients calling SharePoint. A policy set on Exchange applies to
the attempt to access the email using Outlook client. That is why
client (public/native) applications are not available for selection in
the Cloud Apps picker and Conditional Access option is not available
in the application settings for the client (public/native) application
registered in your tenant.
It also explains why CA is not applied when you tried to login using the App Registration -- you didn't call a service.
We are migrating part of our web app to a native mobile app (iOS and Android). We store all user info in our own database, including authentication info (username & pwd). We have a REST API for use by mobile apps and are trying to implement that in Google Cloud Endpoints.
We use an API key for identifying the app.
We want to also authenticate each user. The app will request the username and pwd and then pass that through the REST API. Our backend will confirm (by looking up the username/pwd in the db) if the user is valid. Ideally, at this point we would return a JWT.
Can this be done? The GCE documentation talks about authenticating Google users, and Facebook users. We don't want that. We don't want to use Firebase (unless a custom mechanism can be set up to authenticate). We will manage accounts. We will check if the username and pwd provided (through the app) identifies a valid user.
In trying to use a backend based on Google App Engine Standard and ESPv2, the documentation states that IAP must be enabled. IAP appears to authenticate users in a way we don't want. We want to authenticate users based on the username and pwd they provide and that we manage. Can this be done?
Any pointers would be greatly appreciated.
Thank you.
I've read in some IS4 issues recently, e.g. here, that hosting IS4 and a client in the same web application is not a tested or recommended scenario. Does this also apply for when integrating AspNet Identity's logged-in workflows into IS4?
For example, it's understood that AspNet Identity's Account feature's controller, models and views from AspNet Identity are required so that IdentityServer4.AspNetIdentity code can initiate the relevant UI, but is it okay to leave the Manage controller in the same web application so as to provide a self-service feature, or should this functionality be moved to a separate web application?
For IS3 I created a separate web app that contained user profile functions (Manage controller), plus admin for the IS3 configuration and user management. This app was configured as a client and the IS3 web app itself had no client config or logged-in workflows. Is this the preferred architecture for re-using the Manage controller functionality?
Ideally, I'd like to keep AspNet Identity functionality together with IS4 in the one web app and have a separate web app for admin of config and users. Just want to be certain I'm not opening up a security vulnerability by doing so.
I have an node.js application with a working server2server GMail API communication via an service_account.
Everything works fine.
To be able to communicate with a users account, the G Suite Admin has to grant API Acess to the Client ID of my service_account manually.
As described here:
Impersonating list of users with Google Service Account
with a Marketplace App it would be possible, to grant access only to specific organizationals units (OUs) and it would be more fancy to use (enabling a marketing place app is more user friendly than configuring API Access for ClientID and Scope manually like here:
)
Now my question: Is it possible to provide a Marketplace App only for the purpose to grant API access for my application automatically? Will it get through the review when it has no other purpose? Any other hints on this?
Yes it is a working way to create a marketplace application to grant the API access automatically when the G Suite Admin installs this application.
The only restriction is, that your actual application has to support Google SSO to make it through the review process. So the user must be able to log into your Web Application by clicking on the icon in his G Suite account. If the user has no account in your web app, an account has to be created automatically (trial-account is sufficient)