Scenario 1: Assume I have angular client with implicit grant type. I am also using asp.net identity to log in with database users. I log in as user Bob. I access my list of cars. For each car I have an option to edit my car. Each row has edit button and id of car.
Example of get url in each row: http://localhost:5000/cars/id/1
Let's say I enter randomly some id of car:
http://localhost:5000/cars/id/345 which is someone else's user car.
How does identity server protects other user data in this situation?
Scenario 2: let's have identity manager set up with identity server openid authentication. Which username and password are we authenticating to gain access identity manager to manage users ? If it is user from aspnet identity database then every user inside there can access identity manager...?
They don’t.
It’s not responsibility of Identity Server.
Identity server main responsibility is to take care of Authentication.
Scenario 1
Authorization is not part of identity server except for basic client/scope based authorization defined in OAuth. Identity server just handles the authentication part. Have a look here for implement authorization on an asp.net core app. https://learn.microsoft.com/en-us/aspnet/core/security/authorization/resourcebased
Basically, Identity server gives the user identity. So you can validate if that user has access to the given resource.
Scenario 2
You can define users with certain role claim(e.g. Role:IdentityManagerAdministrator) in your user store, and validate if the logged in user has that role in identityManager. see
Secure IdentityManager with IdentityServer3
Related
I'm trying to set up Identity Server in a multi-tenancy environment but I'm struggling to get the ClientCredentials Grant Type and how I can audit record changes.
If I use the code flow grant type I obviously have a user & roles. I can then create an authorization policy based on the roles and the user. i.e. must be an authenticated user and have role "x".
As I have user data (and tenant data), I can then update my records with which user updated the record. e.g. Customer Bob was updated by user 999.
But how is this possible with an m2m account which I understand should use client credentials?
So Customer Bob is updated by the m2m account but who/what do I say updated the record? I understand that an m2m account doesn't have a user but something has still updated the customer record. I hope that makes sense.
I'm working on improving the user experience for our org when logging into snowflake. We have adfs sso enabled and are provisioning mapping users to roles using azure ad. I had a colleague attempt to sign in with SSO who didn't have a user account created in snowflake and they were greeted with
"The signed in user <user#email.com> is not assigned to a role for the application (Snowflake)".
My question is, is it possible to have users sign into snowflake without being mapped to a default role, perhaps only have the public role assigned, and without being synced with azure ad.
If it is, i'd appreciate any pointers to documentation i can reference. The goal is to get all users that can SSO, to by default be able to login
AD group syncing occurs every 40 minutes in Microsoft, and I don't believe it's possible to force a sync or change this time frame. In addition, like the OP mentioned Snowflake cannot connect to an on-prem ADFS server so all users must be in Azure AD.
AD group syncing is somewhat configurable via the "Scope" (see Step 15 of this tutorial)
If your Scope is set to "Sync only assigned users and groups", you can either
Change the scope to "Sync all users and groups" (may cause issues if you don't want to import all this data into Snowflake)
or
Confirm that your desired users' AD group is one of those assigned to be synced to Snowflake (requires manually assigning these users, or that all of these users are part of the same AD group that you choose to sync to Snowflake).
By seeing the error its not allowing user who don't have appropriate role for the application.
In these why can't we create generic stored procedure to assign default role and instance to new user based on the group they belong to.! Each time if we add any new user then we have to run stored procedure to assign default role and object prior to his login to snowflake.
I'm attempting to develop a .NET Core Identity Server but I can't seem to figure out where to hook in to persist consents in a database. My understanding is that when the use consents to the scopes of an application and checks the Remember Consent checkbox that in only stored in memory by default and if the Identity Server were to restart, the user would have to consent again. Is there a way to persist consent in something like a database so it can be remembered beyond a service restart?
you can use something like Entity framework to persist data in the database,
here is the docs for how to configure EF with Identity Server.
I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.
I have been trying to add a "virtual" claim provider (SAML 2.0 Identity Provider) in ADFS, I have another claim provider with same certicate. I get this error on ADFS2.0 in windows Server 2012
MSIS7600 Each Signing Certificate value for a claims provider Trust must be unique across all claims provider trusts in ADFS 2.0 configuration
Is there any workaround to avoid this issue?
No, I got the same thing here. Appearantly it must be unique. I tried to add 2 tenants (2 customers) coming from Windows Azure Active Directory where all claims of all tenants are signed with the same certificate.
The first one works perfectly but on the second one the MSIS7600 refuses to let me add the second Claims Party.
We had the same thing here and solved it by using this trick
We created a new Azure AD with the purpose that this is the one we are going to add in ADFS.
For each customer tenant we want users to be able to login, we asked asked for read permissions to this tenant; this way it it added in your own subscription. We then selected the users from the customer tenant and added it to the Azure AD we are going to use in ADFS.
We connected ADFS to this Azure AD
All our customers can now login to the ADFS using their own credentials. The only thing we have to do is adding the existing Azure AD users from their own tenant to our Azure AD.
This way it let's you to add as many customers or external Ad's if you want and also not "showing" all tenants in the list of the ADFS page. Because there is only one tenant in ADFS there is no complain of the error MSIS 7600 and you don't have to update all tenants seperately.
Philippe is right. You can use AzureAD B2B feature that allows you to login in any Azure AD user in any tenant to be able to login. This is done by invite. This feature is in preview. This is the simplest choice. However, from an ADFS perspective, policy is on only a single entity. Home realm discovery can be a little more tedious.
We've also fixed ADFS 2016 to relax this constraint for a few reasons. We now constraint it on "Cert + claims-provider-identifier". In this world you will be able to add any # of Azure AD tenants distinctly. This fix will be out in the next preview (should be out soon).