We have 2 micro services.
account micro service (for registration, verification, etc..).
e-wallets micro service (create a wallet, deposit, withdrawals, etc..).
the application first creates an account and then creates an e-wallet for every verified user.
considering the user identity is manged in the account micro service.
should the wallet service store a reference to the account entity (external-user-id)? or should the account micro service store a reference to the wallet entity (external-wallet-id)?
i am mostly concerned with the account micro service becoming a hub which stores many references. are there any practices i should consider?
You probably want to have the client or the creator of the account to generate the account Id using a guid then send a message to the account components and the wallet component to create the account and wallet using the generated aacountId and WalletId...
Make sense?
Related
In my project, there is a mobile app, an angular web app, 4 micro services and one api gateway. The users with role 'agent' can enroll customers using the mobile app. The web app is for users with role 'manager' to see the customer data and finalize on the customer enrollment.
Here, if I want to set up Keycloak for authentication, should I add
every micro service as a separate client ?
Should I add mobile app and web app as separate clients in keycloak ?
CLIENTS
The web and mobile app must be registered as separate OAuth clients. They will have a client ID but no client secret since they are public clients. They will use PKCE and have different redirect URIs, eg:
Web: https://www.example.com/callback
Mobile: com.example.app:/callback
APIs
By default APIs do not need to be registered as clients. In most setups related microservices can just forward JWT access tokens to each other, as explained in the scopes article. This is a secure way to maintain the user identity.
APIs sometimes act as clients though, eg if they need to do something like create users in Keycloak programmatically. Identity systems provide User Management Endpoints to enable this.
So one of your APIs, eg a Users Microservice, may need to be registered as a client. It would use the client credentials flow to get an access token with a SCIM related scope.
GATEWAY
It is common, and recommended, for a gateway to act as an introspection client. This enables data in access tokens returned to internet clients to be kept confidential. Read more about this in the phantom token pattern.
I have been working with the Android Management API to try and manage the policy of my company's existing enterprise. My company account has the Owner role within the organization and the roles Owner and Service Account Admin for the service account mentioned later.
I followed the Quickstart Guide to get familiar with the API and made some modifications for a more permanent solution along the way such as creating a service account with the Android Management User role via the Google Cloud Platform and generating a JSON key to acquire credentials rather than going through the OAuth2 flow like in the guide. This allowed me to authenticate properly, but when it comes time to patch the policy as such,
androidmanagement.enterprises().policies().patch(
name=policy_name,
body=policy_json
).execute()
I get the following error:
<HttpError 403 when requesting https://androidmanagement.googleapis.com/v1/enterprises/XXXXXXXXX/policies/<policy_name>?alt=json returned "Caller is not authorized to manage enterprise.". Details: "Caller is not authorized to manage enterprise.">
I have verified that the service account I am authenticating with has the Android Management User role, and thus has the androidmanagement.enterprises.manage permission.
I have also attempted to make this call with an elevated admin role in the organization.
Is there a chance that I need to have created the enterprise with my own account to manage the enterprise? The guide suggests that an organization can create multiple enterprises. In which case, would I need to create a new Google account not associated with my organization's enterprise and create a new enterprise that way?
It is advisable to use your own google account to call Android Management API since your organization account may not be compatible with the quickstart.
To access the Android Management API your service account requires the androidmanagement.enterprises.manage permission, which can be granted by the Android Management User role (or roles/androidmanagement.user). Kindly check this link for details regarding creating a service account.
Please keep in mind that the enterprise you created as part of the colab instructions can only be managed using the colab itself. To allow your cloud project to manage an organization, you will need to create one using the client configuration from your cloud project.
I want to create Microsoft Teams search messaging extension with OAuth.
The problem is, our customers host their servers, and because of that, they have different Authentication servers.
For example there is 2 company, Company1 and Company2, and they have 2 servers, company1.com and company2.com, and they have 2 Authentication server (company1.com/auth and company2/auth).
And if a user from Company1 wants to use the messaging extension, the user wants to log in with the company1.com/auth Authentication server.
Is there a solution (what works with 1000+ customer), where every customer can use their own Authentication server to log in? (Without manipulation OAuth Connection Settings in the Bot Channel Registration)
I'm not sure I fully understand the scenario, and I'm also not an auth expert, but perhaps this will help: You could register multiple OAuth connection entries with the bot, inside the Azure portal (i.e. one for Company 1 and one for Company 2). Next, inside your bot, when the message extension is invoked, it passes along the tenant id of the user who invoked it, and you could use this to perform a lookup against which OAuth connection to use.
Our current API use seesionID for the authentication. We plan to use Azure API management to manage our web api. However Azure web api management has their own authentication. How can we link those two together. Our customer can use the same logon information.
Conversations about authentication and identity in Azure API Management can get tricky because there can be three different identities and then there are the different contexts of runtime requests vs management requests. So, to be sure I'm answering the right question, let me try and get some terms defined.
The three identities:
API Provider: This is the Azure user who has created an API Management instance.
API Consumer: This is a developer who is writing some client software to consume the API.
End User: The user of the application written by the API Consumer and will be the one who actually initiates runtime requests to the API.
I am assuming that you are the API Provider. What I'm not sure about is whether your customers are the API Consumers or the End Users.
Azure API Management provides identity services for API Consumers. Consumers can either manually create a username/password account or use some social identity provider to create an account. They then can get a subscription key that will allow Azure API Management to associate requests to the API Consumer.
I think you are asking if you can connect the sessionID, which I am guessing you use to identify End Users, to a subscription key used to identify API Consumers. If that is correct, then the answer is no (except for the scenario described below), because we need to identify the API Consumer key before any policies are run to ensure we run the correct policies.
You can change our Api Consumer subscription key. So, if you only have a low quantity of customers/End Users you could create an Api Consumer account for each End User. However, you would only be able to map sessionID to API Consumer Subscription Key if sessionID was a constant value. I'm presuming based on the name, that value changes at each login.
Although Azure API Management provides identity services of API Consumers, it does not provide full identity management for End Users. We leave that to external partners like Azure AD, Thinktecture Identity Server and Auth0. I'm assuming that your existing system is already using some kind of identity provider to generate the sessionId. What you can do with Azure API Management is validate that sessionId using policies in the API Management Gateway. To do that we would need to know more about the format of the sessionId.
Sorry for the long post but it is a confusing topic and I wanted to be as clear as possible.
Is there other ways of authorizing against the Azure Service Bus using AMQP than username and password such as tokens from the ACS?
In my scenario I want to be able to give resource level client access to the service bus without exposing my credentials.
Today, in the preview release of AMQP support in Service Bus, the SASL username/password scheme is the only authentication option.
It is still possible to provide resource-level client access with this model though as you're free to create multiple identities within ACS and associate a limited set of claims with those identities. In fact, this is recommended best practice. The alternative of using the default namespace 'owner' identity in a production set up is analogous to giving application components access to the root password.
So, my recommendation would be to create ACS identities for each "role" in your application and then grant only the claims required by that role. For example, if a Web tier component requires the ability to send to a queue, q1, then create an ACS identity for this Web tier role and grant the 'Send' claim to that identity.
Thanks,
Dave.
Service Bus Team, Microsoft.