Showing posts with label Request Unit. Show all posts
Showing posts with label Request Unit. Show all posts

Monday, August 19, 2019

Request Unit in Azure Cosmos Database

In Azure Cosmos DB, throughput is the rate at which data is processed. It's measured in Request Units (RUs). An RU is the amount of CPU, disk I/O, and memory required to read 1 KB of data in 1 second. Other operations like reading more data, writing data, or querying data take more RUs. The greater the demand on the underlying physical resources, the higher the number of RUs used.
The number of RUs that a specific operation uses depends on the following factors:
  • How the data is distributed across the physical resources in Azure
  • The volume of data that's read and written
  • Whether the operation is a read or a write
  • The number of fields in your database that are indexed, and the indexing mode
  • The complexity of the operation for queries
  • Data consistency for geographically replicated collections
When you create an Azure Cosmos DB collection, you configure a fixed maximum number of RUs. The sum of RUs that all of the operations consume on the collection must be less than this value. If you exceed this value, requests to the database are throttled.
To operate an Azure Cosmos DB database efficiently, you need to:
  • Configure enough throughput to meet performance demands.
  • Minimize unused excess throughput to keep your costs down.
  • Regularly review metrics to maximize the efficiency of your provisioned throughput.
RUs are billed on an hourly basis, whether you consume them or not. The amount that you're charged for your Azure Cosmos DB collection is fixed. It's based only on the configured capacity in RUs.

Wednesday, August 14, 2019

Dynamics 365 Portal Authentication - Using OAuth2.0 Providers

The supported OAuth2.0  providers are:
  • Microsoft Account
  • Twitter
  • Facebook
  • Google
  • LinkedIn
  • Yahoo
They all involve registering the portal application with a third-party service to obtain a client ID and client secret pair. A redirect URL needs to be specified that allows the identity provider to send users back to the portal.

How to configure for Google

  1. Open Google Developers Console
  2. Create an API project or open an existing project
  3. Go toAPIs & auth >APIs, and under Social APIs, selectGoogle+ API, and then selectEnable API
  4. Go toAPIs & auth >Consent screen.
    • Specify anEmail address.
    • Specify a customProduct name.
    • SelectSave.
  5. Go toAPIs & auth >Credentials and create a new client ID.


How to configure for Facebook

  1. Select Add a New App.
  2. Select Website.
  3. Select Skip and Create App ID.
    • Specify a Display Name.
    • Choose a Category.
    • Select Create App ID.
  4. While on the dashboard for the new app, go to Settings >Basic (tab) and add the following details:
  5. Select Save Changes.
  6. Go to Status & Review > Status tab.
  7. Select Yes when prompted to make the app and all its features available to the general public. You must have filled in the valid data in Step 5 above to enable this setting.

How to configure for Microsoft

  1. Open Microsoft account Developer Center
  2. Select Create application and specify an Application name.
  3. Select I accept to accept Terms and Conditions.
  4. Go to Settings >API settings, and then set the redirect URL as http://portal.myexample.com/signin-microsoft

How to configure for Twitter

  1. Select Create New App.
  2. Select Create your Twitter application.

How to configure for LinkedIn

  1. Select Add New Application.
  2. Select Add Application.

How to configure for Yahoo

  1. Select Create an App.
    • Specify an Application Name.
    • Application Type: Web Application.
    • Callback Domain: portal.myexample.com
  2. Select Create App.

Following site settings need to be configured on the portal (replace [provider] with google,facebook,twitter,linkedin,Microsoft,yahoo depending on which one is getting used) :

Site Setting NameDescription
Authentication/Registration/ExternalLoginEnabledEnables or disables external account sign-in and registration. Default: true
Authentication/OpenAuth/[provider]/ClientIdRequired. The client ID value from the provider application. It may also be referred to as an App ID or Consumer Key. The following setting names are allowed for backwards compatibility: Authentication/OpenAuth/Twitter/ConsumerKey
  • Authentication/OpenAuth/Facebook/AppId
  • Authentication/OpenAuth/LinkedIn/ConsumerKey
Authentication/OpenAuth/[provider]/ClientSecretRequired. The client secret value from the provider application. It may also be referred to as an App Secret or Consumer Secret. The following setting names are allowed for backwards compatibility: Authentication/OpenAuth/Twitter/ConsumerSecret
  • Authentication/OpenAuth/Facebook/AppSecret
  • Authentication/OpenAuth/LinkedIn/ConsumerSecret
Authentication/OpenAuth/[provider]/AuthenticationTypeThe OWIN authentication middleware type. Example: yahoo. authenticationoptions.authenticationtype.
Authentication/OpenAuth/[provider]/ScopeA comma separated list of permissions to request. microsoftaccountauthenticationoptions.scope.
Authentication/OpenAuth/[provider]/CaptionThe text that the user can display on a sign in user interface. microsoftaccountauthenticationoptions.caption.
Authentication/OpenAuth/[provider]/BackchannelTimeoutTimeout value in milliseconds for back channel communications. microsoftaccountauthenticationoptions.backchanneltimeout.
Authentication/OpenAuth/[provider]/CallbackPathThe request path within the application's base path where the user-agent will be returned. microsoftaccountauthenticationoptions.callbackpath.
Authentication/OpenAuth/[provider]/SignInAsAuthenticationTypeThe name of another authentication middleware which will be responsible for actually issuing auserClaimsIdentitymicrosoftaccountauthenticationoptions.signinasauthenticationtype.
Authentication/OpenAuth/[provider]/AuthenticationModeThe OWIN authentication middleware mode. security.authenticationoptions.authenticationmode.

Source of this article is https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-oauth2-settings



s

Dynamics 365 Portal Authentication Basics

Dynamics 365 Portal authentication is built on the ASP.NET Identity API which in turn is built on the OWIN framework.
1. Local Authentication
It is the common forms-based authentication which uses the contact records of a Dynamics 365 to store the authentication details( password as hashed text, username etc.) It is going to be deprecated soon. 
2. External Authentication
It uses the ASP.NET Identity API to integrate with the external ID providers. For example. Open ID based providers such as Azure AD and Google, OAuth 2.0 based providers such as Twitter, Facebook, Yahoo, Google and Microsoft, SAML 2.0 based providers.
When using external authentication, the user is required to sign in through the chosen identity provider to prove that they own the external account. During sign-up, a new contact record is created in Dynamics365. 
For portal authentication to work properly, ensure that following solutions exist in the environment"
  1. MicrosoftIdentity
  2. MicrosoftIdentityWorkflows
  3. Microsoft IdentitySystemWorkflows
    Users who have an external account can choose to create a local account by applying a username and password. Users who started with a local account can choose to associate multiple external identities to their account.
     

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/set-authentication-identity has most of the site settings which needs to be configured for either local or external authentication.