I recently started studying ADB2C.
Therefore, I would like to know the maximum number of users I can register with ADB2C.
You can create 50M+ users. You do not need to contact Microsoft. AAD B2C tenants auto scale for number of objects.
You are not charged for users. You are charged for unique authentications per month.
Microsoft will happily bill you for as many users as you want past the 50,000 free threshold. https://azure.microsoft.com/en-us/pricing/details/active-directory/external-identities/
Related
I am creating a login screen with ADB2C.
I has two questions.
1:I want to limit the number of simultaneously active users to 150.(Maximum number of simultaneous connections)
　Where can I set it up?
2:I want to display an error when the configured limit of active users is exceeded.
Where can I set this up as well?
thank you.
AFAIK, In case of azure ad B2C ,limiting concurrent active users is
not yet supported.
According to token-issuance-rate
Each type of User Flow provides a unique user experience and will
consume a different number of requests. The token issuance rate of a
User Flow is dependent on the number of requests consumed by both the
static and dynamic endpoints.
Reference for userconsumption related limits
If you already knew the users characteristics and want to restrict
users based on that , the recommended way to control the access in
Azure B2C is defining custom attributes and check the claims in
token. If the expected claim is included, you allow the user to
continue.
You can check and handle the possibility of microsoft graph
throttling from this link
Throttling limits the number of concurrent calls to a service to
prevent overuse of resources. Microsoft Graph is designed to handle a
high volume of requests. When throttling occurs, Microsoft Graph
returns HTTP status code 429 (Too many requests)
References:
azure active-directory-b2c service limit
b2c userflow identity-protection-investigate-risk
I am setting up Azure API Management with 2 different products that offer different access and restrictions to the underlying API.
Ideally I would like subscriptions for each product to have a different length of time that the user can access them for before it needs to be renewed. I am not finding any type of auto-expiration date for subscriptions when I approve them.
Is there a way to do this that I am missing?
You can create product specific policies that check the time since the subscription was created and deny access if necessary. See context.Subscription.StartDate here https://msdn.microsoft.com/en-ca/library/dn910913.aspx
Is there a way to create a group admin using the API?
Someone who is able to add and delete users from the group but not from the general administrator account?
I can see there are only 3 permissions profile that can be assigned to a group, Administrator
Thanks.
Currently DocuSign does not use a tiered administrator structure with either the API or their standard console.
Several DocuSign employee's that I've talked with have suggested that a tiered structure is in the works but they don't have a release date for that as yet.
As a temporary fix to this, if you have an account administrator at DocuSign (and depending upon your account set up) you can request that they create sub-accounts to which you can assign groups of users and limit administrators from reaching other accounts. This is the solution we used for multiple business units that didn't need access to each others documents.
You can create more permissions profiles, but the degree to which your users can access settings remains largely the same.
Hope this helps.
From web search it appears that to be able to manage Windows Azure services, you need an account with one of the admin roles (service administrator, co-administrator etc).
From project management point-of-view, what is a good strategy to manage accounts for your company if you have several developers working on Azure?
Examples
A simple strategy could be to have a few designated administrators (e.g. team leaders) who upload the code while other developers use Azure Emulator on their machines.
Another example would be to have a shared Azure account used by many developers (not sure about licence implications for this one!).
These are just off the top of my head and have their drawbacks. What strategies do you use?
2 Places I've worked we've done the following.
Single Common A/C
Create a common email-distribution group (myteamonazure#mycompany.com)
Register this mail address as an MSN Passport
Use it to sign up with Azure.
Pro's: Everyone on the team gets mails regarding the account.
Con's: If someone leaves the team, we need to change the account password.
Individual accounts
Let each person signup with their own account. (Mandate it must be their company email... not personal msdn passport)
Make one person the super-admin, and the rest co-admins
Pro's: If someone leaves, it's far easier to just revoke their credentials/privs
Con's: Lots more accounts to keep track of depending on the size of your team, particularly if you're company has a single Azure Account, with lots of different apps/projects hosted on it.
Personally, I prefer the second option as it's more secure/easier to revoke access to individuals.
We have a Salesforce app where we have some custom objects and want to expose the various custom object rcords to customers.
We need to ensure that customers can see only the records belonging to their Account. Because of the way these records are setup(owned by various system users at different levels of processing), we cannot use owner based sharing...and cannot use criteria based sharing since its not dynamic(I cant use criteria based sharing to say "Share this record with all customer portal users who belong to the same Account as the record" at runtime).
So I know I have to use Apex based sharing. I have read up on the sharing objects and the sharing table. But how would I approach this.
I can write a trigger which upon inserting will create a share object and get all userids who belong to the customer portal group and whose account equals the account of the record and associate them with the share object of the record.
But I feel this is overkill correct? Lets say there are 5 users from one of our customers and lets say there are 500 records created a day...that means 2500 share objects a day just for 1 customer...for 10 customers this can go upto 25000...and scale in this way...
Am I right here?
Another problem would be if a new person joined that customer team..unless another process updates the sharing on older records, he/she cannot see the older records.
So is there a better/elegant way to do this? I thought of adding a share object to the group...but there is just one group "Customer portal group" and how do I associate the group with the account of the users?
I will appreciate any thoughts about this.
You should take a look at high-volume customer portal users. They're much cheaper relative to standard customer portal users and should meet your needs. Unlike regular users they have a totally different sharing concept. In a nutshell if they own an object they can see, if not they can't. You can then extend this based on whether a contact or account lookup on the object matches the logged in user.
Read up on this documentation:
License Types (scan to High Volume Customer Portal)
Granting High-Volume Portal Users Access to Records (login required)
You can use groups for sharing to avoid creating so many sharing records. You would have one group per account and one sharing record per account. Instead of managing thousands of sharing records you would have to manage hundreds of groups.
I haven't tried this approach with this many groups, but I read some time ago that it should work (someone posted using a LOT of groups for sharing). If you do try this, please tell us if it worked OK.