Piggy backing off this question. Is it a safe assumption that group ids GUIDs are unique throughout the whole Azure AD directory? Or are they just guaranteed unique within tenants?
Specifically talking about the Group Resource type ID from the: Microsoft Graph
Yes , group ids are unique throughout the whole Azure AD directory.
Hope your doubt is clear now.
Thanks
Related
In our SQL tables we have columns such as UpdatedBy and CreatedBy with a ref key to a User table. This is useful to keep track of who created/updated an business entity.
However we are migrating from this local User table to using Azure AD. We will use Azure AD for authentication and authorization in our client applications.
There should be no need for a local User table (or any other tables related to identity, such as Role etc...), but then how do I reference user ids from Azure AD into my audit columns? Obviously I can no longer have a reference key with constraint.
What is the usual approach to this?
Did you read about System for Cross-Domain Identity Management (SCIM)? You can provide out of the box mechanism for syncing Users and Groups created in the Azure AD.
There is a whole tutorial about how to do that:
https://learn.microsoft.com/en-gb/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#step-4-integrate-your-scim-endpoint-with-the-azure-ad-scim-client
There is a ready to go CRUD and SCIM based application in C# created by Microsoft https://github.com/AzureAD/SCIMReferenceCode
That will give you a solution what to do for example when Azure AD is removing the user, but you want to keep it.
We are running single database for rest app server. We have three types of users
for customer
for administrator, and
for partners
Currently they have different tables and username and password are also in separate respectively Now We need to refactor this schema as user are expanding.
So should a single table User with Role table is OK ? (Here Role can be admin, partner or customer, manager).
OR
Should we a keep as it is as We will be having issue if we use User and Role table:
if an admin acquire a username then that username can not be the same again for customer or partner due to unique constraint.
I think user role can not be as "Customer" as customer is not a Role. Role can be admin, manager etc
I think this is not the right way to keep in single table. What are your suggestions?
I think you should create three tables for your user management, considering the fact that one user can have several roles (ex:- admin can also be a manager Or Customer can also be a partner). So User table and Role table have a Many-To-Many relationship. In order to create this relationship, you have to create 3rd table having userId and roleId as composite primary key.
additionally, i noticed that you are going to save user's passwords in the database. For the security reasons do not store passwords in plain-text. Instaed store the hash of the password using one way hashing algorithm.
You can read more about it from here -> Best way to store password in database
Yes, it would be better to keep separate tables because of the following reasons:
1. As you specified, Customer is not a role.
2. Since administrators would be limited in number, there is no point in fetching the record for authentication/authorisation from a large data set having the customers. It will hinder the performance.
User
id
userId
role (foreign key)
etc..
Role
id
name
etc
the above structure is best practice.
if you really need extra fields for admin, partner or customer
you can create separate entity for each one and you can refer user as a foreign key like as follows
Customer
id
name
user(foreign key)
etc
Documentation on Azure Search says I can use Azure Sql server as a datasource(https://azure.microsoft.com/en-us/documentation/articles/search-howto-connecting-azure-sql-database-to-azure-search-using-indexers-2015-02-28/). Can I do the same with an on-premise SQL server?
I have a typical relational structure like
User Table -> Address Table
User Table -> UserDetails table etc..
All linked to each other via foreign keys. My search should end up with an UserId, so I can link to my UserDetailsPage.aspx?UserId=xxx
What will be the best suggested way to build the datasource? Should I Create a view and apply change tracking on it? or Should I create a different datasource for each table and sync the concerned index?
Please shed some light on best practices in a typical relational database scenario.
you would need to allow the IP address of your search service to connect to your on-prem DB.
In terms of view vs. multiple indexers targeting the same index - both approaches might work. What info will your users be searching on - address, details, or both? If it's only one of those, then you wouldn't have to index both tables.
Keep in mind that if you decide to index a view joining both tables, you won't be able to use SQL integrated change tracking, and will have to rely on a rowversion or timestamp column in the view.
HTH
I am looking for a way to get a unique ID per database itself. The idea is to exchange objects between different installations of my application. Therefore I have unique IDs for all objects within a single database, but in order to exchange these objects to other databases with the same schema, I introduced a composite ID consisting of a primary and a secondary ID, where the primary is unique within a single database and the secondary should be unique across multiple databases with the same schema.
Does somebody knows a decentralized solution for this issue?
Using a global unique identifier for each row solves the problem. Java itself provides a UUID generator, but there are more (better) third-party generators as well.
I am stuck with a problem of implementing security at dimension level in SSAS. Here is what I did -
1. Defined a role in SSAS and applied security at dimension level (Unchecking cube dimensions that I don't want this role to access and setting Allowed & denied Sets).
2. Tested using Cube Browser, it worked fine.
3. Tested using SSRS, no change, I was still able to query the dimensions & get results that I don't want.
Question - Is it possible to propagate the security I define at Cube level to SSRS? I would like to believe yes it is.
If yes then here is what I need -
Users will logon to the Report Manager using Windows Identity (Integrated Authentication on IIS turned on -done)
Capture this identity to find out SSAS role that they belong to - I guess this would be through a query, does not seem to work automatically (How to do this?)
User works within the restrictions of this role in SSRS (role based security applied at SSAS level) i.e. if dimension X is not available to user, he/she should not be able to query it. (How to do this?)
I have referred quite a few blogs on this and even found one - http://www.sqlmag.com/Article/ArticleID/96763/sql_server_96763.html
but this one seems to have more information on how to set it up within SSAS, rather than how to use this in SSRS.
Anyone who has worked on this approach OR have an understanding of this please let me know.
I think you need to look at your datasource in SSRS on the report server, and make sure it is set to use the logged in users windows cred's once authenticated, it might be what you are looking for.
All you need to do is:
In the data source in SSRS report, specify the Role Name created in SSAS database like this:
Data Source=LOCALHOST;Initial Catalog=XXXXX;Roles=RoleName
Thanks
Sameer
I haven't done this in SSAS, but I've done it in the engine. Jeremiah Peschka has a blog about row-based security setup, and if you're going to do this with integrated Windows security, then you can use the user_name() function to grab the current login's name. You'll be using a lookup table for each dimension, with a row for each dimension row plus the user's name. When querying, join to the dimension security table like this:
FROM dbo.Customers cs
INNER JOIN dbo.CustomersSecurity css ON cs.CustomerId = css.CustomerId AND css.UserName = User_Name()
That way, your join will only return records for customers that the user can see.
The drawback is that if you're using partitioning, the engine won't build a good execution plan to only pluck the right records from the right partitions based on what your user can see. For example, if you log in as a user that can only see records in Florida, and your data is partitioned by state, it won't matter - the engine will still scan all partitions, because it won't be able to predict the user's info when the plan is built.