Can we have two sets of Azure B2C sign-in custom policies for the application? - azure-ad-b2c-custom-policy

I have a requirement to project different type of B2C sign-in page to end user?
For example,
User type-1: will be using the user name or email-id to sign-in with self service password reset option. (B2C_1A_SIGNUP_SIGNIN - File 1)
User type-2: Will be signing in only by using the user name and no Forgot password link and self service password reset option provided. (B2C_1A_SIGNUP_SIGNIN - File 2)
Based on my understanding, I will have to create two different custom policy for user type 1 & 2? Is that right? If yes, how about B2C_1A_TRUSTFRAMEWORKBASE and B2C_1A_TRUSTFRAMEWORKEXTENSIONS files - do I need to have seperate copy of these w.r.t user type please? Thanks.

No need to keep seperate B2C_1A_TRUSTFRAMEWORKBASE and B2C_1A_TRUSTFRAMEWORKEXTENSIONS files. Just have 2 different relying party poicies. And have 2 seperate User Journeys in Trustframeworkbase file.

Related

Check user group of already logged in user in KeyCloak

I have two application, both are using keycloak to authenticate user of the same realm. I've created two different client, and two different user group. Only users of a specific group can access to corresponding application.
I'm using this custom extension to verify user group after user login. I've created two different user flow based on Browser Flow, one for group, and I've configurated each client to use the relative user flow. This is working fine when a user tries to login.
I'm giving an example to better explain:
I have two group A and B. One user belongs to group A. When the user isn't logged, he can access to application A but he can not access to application B.
What I cannot prevent is user access to application B when he is already logged into application A.
This is happening because Browser Flow has a cookie step that gives authorization of users already logged.
Is there a step to check user group (or other user information) after the cookie step?
I found this solution:
I created a new authentication flow, at first level I've created a sub flow containg the standard Browser Flow and always at first level I've added the execution of group verification.
Both step at first level are marked as required.

Set Password email by application

I have 2 applications on the same Tenant.
I can configure an email template for the "Set Password" workflow on:
an Application Level
the Tenant level
When I register a new user using the UI, as far as I understood it will only be able to send the email configured on the tenant level since it won't know anything about which application the user can see until the next step when I add the registrations.
If I create a user and add registration to it right away (on the same step) then this takes the Template configured on the application level.
My questions are:
Can we do something like this through the UI interface too? My applications have a different user base (some have accounts on both) and it would be nice to be able to send them one email or the other.
Or is this only possible through the API?
If I register a user with both applications (through the API) which email do they get?
Thanks for the help!
Can we do something like this through the UI interface too?
This is not currently possible. Creating the User, and creating a User Registration are two separate steps. As you correctly stated, when creating the user in the UI, there is no context yet for an application. For this reason, the user will receive the template configured at the tenant level.
Or is this only possible through the API?
Correct. You must use the Create "User + Registration" API to do this in one step to use the application template for setup password.
If I register a user with both applications (through the API) which email do they get?
When using the API to Create "User + Registration" you can only register for one application at a time. The email is only sent during the User Create step, so if you register for a second application, the user will already exist and thus will not receive a second email.

What are all possible values that can be passed for "scope" in box content API auth?

Box documentation at https://developers.box.com/docs/#oauth-2, says that user is redirected to authentication page in first leg of oAuth, and application can pass a parameter "scope".
scope: What scope the eventual auth token will have. This field is not required. If not specified the application will get the default scope configured. If your application has different kinds of users that may need different types of scope, then you can provide a comma separated list of scopes, to give some users a lower scope if they sign in from different locations. If you are using a Provision-granted application, you must specify the alias: folder_readwrite to use the auth-code grant.
Type: string
But I could not find what are all possible values that can be passed as scope.
Any help is greatly appreciated.
My requirement is to restrict the login to only box admins, if someone has any other ideas then please share.
If you still need help with this, to see all the possible values, check all the scopes in your app (actually select the all the checkboxes). Then, in your initial request to Box (i.e. https://app.box.com/api/oauth2/authorize) do not include a scope parameter. You will be redirected to a Box authorize page (login if necessary). There should be a hidden input with all the possible scope values.
From my scope settings I received this hidden input
name="scope" value="root_readwrite manage_enterprise manage_managed_users manage_groups manage_enterprise_properties"
Hope that helps!
Using beast's answer I was able to find the appropriate documentation page:
https://developer.box.com/v2.0/docs/authentication#section-oauth-2-scopes
Here's what it says at the time of writing:
root_readwrite - Read and write all files and folders
manage_enterprise - Manage an enterprise
manage_managed_users - Manage an enterprise's managed users
manage_groups - Manage an enterprise's groups
manage_enterprise_properties - Manage an enterprise's properties
manage_data_retention - Manage an enterprise's retention policies
manage_app_users - Create and manage app users
manage_webhook - Manage Webhooks
They also have a few scopes that require filing a support ticket (no OAuth2 name provided):
Global Content Manager
Admin can make calls on behalf of Users
Can suppress email notifications from API calls

ASP.Net MVC 4 How to create a simplemembership account without a password

I am building an MVC4 app in which users will be registered by a site admin. The site admin will enter everything but the password of course. I then generate a token and send via email for them to set their password. However, I don't see a way to create a user without a password. I can either randomly generate one or assign one in the code. What is the best way to handle not having a password at account creation?
EDIT:
I used Membership.GeneratePassword for generate the password when I created the account.
Create a random password and allow them to change once the account is confirmed. Solves a number of problems.

Associate multiple claims based identity providers to one user with ASP.NET

In an ASP.NET MVC 4 application using the .NET 4.5 framework in conjunction with Azure Access Control Service (ACS), I want to provide the users multiple authentication possibilities (i.e. Google, Facebook, Windows Live, etc.). What is the "best practice" for associating a single user to multiple identity providers?
For example, say the user logs in with Google one day, then goes to another browser the next day and logs in with Facebook. How would I know to associate the Facebook login with the previous Google login to the same user?
Look no further than stackoverflow itself for a good example of this. Click your user profile and then select "my logins".
When a user creates their account, they select which identity provider you want to use to sign in. Under the hood, your application creates a new site-specific unique user ID, and links it with a 3rd party provided unique ID. (You might use email, but most identity providers will also provide a unique user ID claim that doesn't change, even if the user changes their email)
Now, after the user has signed in, they have an account management control panel through which they can establish additional links to other identity providers.
I see two options for achieving this:
Have your MVC application persist account links. When a user signs in, you query your account link store using the 3rd party unique ID claim and resolve your site specific unique user ID.
Use the ACS rules engine. You would create one rule per account link. For example, lets say I can sign in with either gmail or liveid and my unique id is 1234. Two rules look like this:
google + me#gmail.com --> output user ID claim 1234
liveId + me#live.com --> output user ID claim 1234
For the unique ID output claim type, you can pick from the available claim types or designate your own. ACS has an OData based management service which you can use to create these rules programmatically from your MVC application. Here's a code sample.
If you are using ACS, you can translate the information from each IdP (e.g. Gogle, Yahoo!, FB, etc) to a common handle using claims transformation on ACS. A common handle people use is the users e-mail. But if you want to accept many e-mails mapping to the same user, then you'd introduce your own unique id (as a claim) and map IdP supplied claims into it:
myemail#gmail.com (e-mail - Google) -> (UserId - YourApp) user_1234
myotheremail#yahoo.com (email - Yahoo!) -> (UserId - YourApp) user_1234
64746374613847349 (NameIdentifier - LiveId) -> (UserId - YourApp) user_1234
You can automate this through ACS API. You should also probably handle the first time user logs in into your site (e.g. asking user for an e-mail and sending a confirmation message that will trigger the mapping).
Presumably, you are using this information to retrieve data from a local database in your app, otherwise, you could just encode everything in claims and not worry about any equivalences. Claims are often a good place to encode common profile data. (e.g. Roles, etc)