Is there a setting to allow only emails from one certain domain, when register users in ASP.NET Identity 2?
You can write a regular expression or a custom code to validate only emails from a specific domain..
You can see an example here:
https://techbrij.com/asp-net-core-identity-login-email-username
Related
I would like to show Identity providers dynamically based on the tenant[ i.e OIDC domain_hint] during the Azure B2C Sign In user journey. I have referred several examples on custom policies, however unable to find a way to display/hide an IdP based on tenant. I was able to use this good example to do Home Realm discovery in custom policy using an Azure Function, but it doesn't show 'list of IdP' applicable for the tenant/domain. Other SO questions, that came close to this but didn't answer are 1, 2. Even if I serve custom HTML file from blob storage, how to show only certain Identity providers and hide some based on the tenant/domain_hint ?
Depending on the number of domains/tenants permutations, you could put that logic on the application side to execute different PolicyID's. This is assuming the number is low therefore it would be a policyID : IdPs mapping.
This is a bad solution if you have a HIGH volume of hints.
Alternatively, you could perform an API call via JavaScript to delegate populating the list of Identity Providers. Then, it would execute another self-assertive page that would trigger that specific identity provider. The flow would look like:
App (passes domain hint)--> B2C login page (JavaScript REST API on page and request list of IdP's based on previous domain hint) --> 2nd Self-assertive page (value passed from first page to initiative the correct IdP) --> IdP pages load.
You can adjust the logic in different ways to meet your needs.
You could store the tenant in a claim using claim resolvers, then have an orchestration step for each possible combination of IdPs you want and use preconditions on those steps to only execute them depending on the tenant. Hopefully that works.
I'm trying to configure a B2C tenant using policies instead of user flows.For that, I'm using the SocialAndLocalAccount template as start base. One of the things I'd like to do is to configure the email's verification parameters so I can choose the code's length, expiration time, etc. I don't really care about having a custom email like the example with SendGrid, just want to be able to configure the basic parameters.
I've been following the otp example they have in the documentation and managed to display the option properly but I never receive the email when clicking on "Send Code". Am I missing something? Is there another way to achieve this?
I'm new to Azure B2C and policies so I would appreciate any suggestions you might have. Thanks!
Currently, if you want to use the custom OTP generation within B2C, you have to use an external mail provider. The built in email verification has a separate combined OTP and mail provider service that is not able to be decoupled.
I wonder if there is a way to add within the Application manifest file (or any other way) to have two (more) "targets" share the same Application ID.
If I register a new app - the appID is new.
Problem is that we have one solution that is configured for SSO but it runs on two domains - for managing languages (as what you see and can do depends on where you log in).
We have somedomain.xa for language XA and somedomain.yz for language YZ. But there are certain URL arguments that *** up the situation as
somedomain.xa --> rewrite --> somedomain.xa/companyID=100&lang=xa
somedomain.yz --> rewrite --> somedomain.yz/companyID=100&lang=xa
And the registration inside the solution is to use company ID, find the AppID from a DB table and then perform the handshake and authentication process. And if I register both domains on same ID, the SSO solution throws error.
Thus my "problem" - of there is a way out?
From your description, it looks like you have one registered application (one Application Id) that runs under the context of one Azure AD tenant, and you want to use this one application to redirect use to either one of the two different domains you have - is this correct?
If this is the case, what you need to do is just configure multiple redirect URLs for this one Application Registration information in portal.azure.com - https://somedomain.xa/page and https://somedomain.xa/page - then use set the Redirect URL parameter when requesting the authentication challenge - in your case as you detect user's language.
I have created a custom timer job in share point 2007 which gets the list of email ids from the database and has to add it to security groups in share point.
I am getting exception "user not found" when i try to verify the user using spweb.ensureuser("emailid") or even add the user to group without verifying.
I have used web.allusers.getbyemail("emailid") as well but results in the same exception.
Also created owstimer.exe.config file with connection string and provider elements but no luck.
Any ideas?
spweb.ensureuser accepts either 1) Login of a user (not email) 2) a Display Name of a user that corresponds to some login. SharePoint has some "storages for logins" like AD or Forms Based Authentcation provider with an underlying services or a database. This means that what you use in spweb.ensureuser must already be found among your logins. you have to add users' logins to SharePoint and the emails will be uploaded automatically. if you want to use pure emails as logins you should learn about Claims Based Authentication in SharePoint and OpenIDs. There are several products which do that (I am not advertising any of'em :) ).
First, a little background: We have an intranet site based on WSS 3.0 that is hosted on a server in DOMAIN_A.LOCAL and set up to use Integrated Windows Authentication to authenticate users against Active Directory user accounts of DOMAIN_A.LOCAL.
This setup works just fine for users who are logged into Windows using an AD account from DOMAIN_A.LOCAL, but when users try to access the site from a PC logged into Windows using an AD account from a different domain (i.e. DOMAIN_B.LOCAL) the following problems occur:
The user must manually enter their credentials as DOMAIN_A\UserName rather than just UserName because otherwise, Internet Explorer automatically inserts DOMAIN_B and causes authentication to fail.
Once logged in, if the user does something that requires the browser to pass their authentication through to a client app, such as clicking on a Microsoft Office document in a document library in order to open it for editing, it appears that invalid credentials (presumably DOMAIN_B) are passed automatically, thus forcing the user to manually enter their DOMAIN_A credentials again.
My question, then is this:
Is there any way to implement a "default domain" type of behavior when using Integrated Windows Authentication (as can be done when using Basic clear text authentication) so that if a user on DOMAIN_B does not enter a domain before their user name, DOMAIN_A is inserted automatically for them?
Of course, I realize this deployment may be fatally flawed, so I am also open to suggestions for a different implementation.
In summary, the main problem stems from two different kinds of users needing to access the same content on one SharePoint site. The users in DOMAIN_A all have their own full-time workstations where they log into Windows as themselves. The users in DOMAIN_B unfortunately have to use shared computers that are logged on using generic "kiosk" type accounts that have no permissions in SharePoint -- thus the requirement that the DOMAIN_B users must provide their credentials on demand when accessing a given page in SharePoint. I would like to preserve the convenience of the Integrated Windows Authentication for the "static" users of DOMAIN_A while minimizing the amount of manual authentication that the "kiosk" users in DOMAIN_B have to endure.
DOMAIN_A.LOCAL must trust DOMAIN_B.LOCAL, otherwise users from DOMAIN_B.LOCAL will receivie a credential prompt since their DOMAIN_B.LOCAL account is unknown within DOMAIN_A.LOCAL.
Given that DOMAIN_B.LOCAL is for kisok users, you probably do not want to trust this domain.
You will need to extend the web application into a new zone and either implement forms based authentication, or use Windows Authentication with a reverse proxy such as ISA server.
I was searching the internet for SharePoint user accounts with multiple domains and came across an interesting tool called Microsoft Front End Identity Manager. Have you heard of it?
So… If your using a multi forest deployment where user accounts are distributed across two or more forests. This is often seen when two organizations merge and need to access domains from both organizations. You can use the distinguished name (ms-ds-Source-Object-DN) attribute in the user object to create an association between the user accounts. In this association one account is considered the primary account and the others are the alternates of the primary account. There is a tool called Microsoft Front End Identity Manager to create this relationship between user account objects. One feature of Microsoft Front End Identity Manager is that SharePoint server can maintain a list of alternate accounts by which the profile is identified. When you use either account to find the profile of a user, SharePoint server returns the primary account profile example (domain\username).
Probably not what you want to hear, but you may want to resort to forms based authentication.
Unfortunately if you want to retain the Microsoft Office integration (which is what it seems you want), you will have to stick with Windows Authentication. Using Forms Authentication will remove most of the features you seem keen to preserve, there is more information here.
Ideally you want to use the suggestion that Jason mentioned, which would be some sort of reverse proxy. However there would probably be a cost implication if you don't already have something like ISA server, so in reality it's probably best for the DOMAIN_B's to learn to type DOMAIN_B\ before their username.