[RETIRED] User Attributes

(Nate Pickens) #1

This article has been retired as the information is now in the Looker customer documentation on this page.

For information on configuring user attributes for hierarchal and multi-dimensional permissioning, see the Advanced Permissioning Using User Attributes Community article.

3 Likes

(Arthur Smith) #2

Ooh, I thought this was going to finally allow use of user attributes as liquid variables - apparently not yet! This feature is something I looked for from the start and it’s been quite a puzzle to work around the lack of it so far. Access filters fill some of this role but it’s not quite enough, for example to allow a dashboard to query for all the accounts a manager is responsible for while also allowing them to query on other accounts in their department also.
From what I can see of this feature it would make sense to replace access filters with it too and the other things mentioned. But liquid variables definitely!!!

2 Likes

(Gabriel) #3

Great to see User Attributes! Is it possible to assign User Attributes via SSO login URLs? If so, where can I find the documentation surrounding this?

0 Likes

(vincent) #4

Hi @gabriel,

That is totally possible, here is an example:

$json_user_attributes = json_encode( array ( "an_attribute_name" => "my_value", "my_number_attribute" => "0.231" ) );  // just some example attributes

Cheers,
Vincent

0 Likes

(Kumaran Raghunathan) #5

Would it be possible to extract the user login information, that is the person signing into the application either using the LDAP/SAML/email authentication methodology through lookML code as this would greatly help us to solve requirement around row level security.

For instance we currently have row level security using access filters, defined at the user level and once we move to 4.8 release we are planning to set it at the group level so its easier to manage but we started getting requirements around more sophisticated requirements around row level security based on the ranking of the user.

For example, if the user is VP of East Cost, he is allowed to see data of all his stores under East Cost but not West Cost or North or South region. Similarly if the user is a Divisional Manager of few stores in East Coast, then he is allowed to see only few stores under the East Cost but not all store data under East Cost and neither West/North/South. And finally when a user is a store representative or a manager of a specific store, then they are only allowed to see data for the specific store.

So the solution i had in my mind was, if we could retrieve the user login information that’s being passed while logging into Looker either via LDAP/SAML or using email ID, basically capture the login attributes of the user through a user attribute variable just like how we use % date_start templated filter and then use this variable to inner join to our primary store alignment data rights table, which would store user login information along with the chain/region/division/district/store information.

Hope this makes sense.

This would greatly help us as onboard more users/customers as you can imagine how hard would it be to configure each and every user profile using multiple level access filters. This solution would reduce the maintenance spent on configuring the access filters for every single user whether spent on user or group level and rather push it on the database front which would be more secured and pre-loaded with all the user login information and moreover this information would always be synced with our customer as they make change to user profiles. That is even if they transfer or change ownership of users from one region to another.

Since 4.10 is currently in pipeline, would it be possible to slate this under your current or immediate release ? This would greatly help us…

1 Like

(sam) #6

Hi @kraghunathan,

I believe what you are looking for is already possible in Looker 4.8.

You can already use User Attributes as a replacement for access filters in the LookML. You can find a detailed example in this article, but basically the syntax is:

You can also set User Attributes at the Group level, as explained in this doc.

Combining these two features together should give the functionality you’re after, if I understand you correctly.

0 Likes

(Kumaran Raghunathan) #7

Yes, i did see it but i am not sure this gives me 100% on what i need. I was looking to retrieve the login information of the user. So for instance if i am logging into the application as kraghunathan@domain.com or kraghunathan-domain name, i would like to store that user_attribute information into a variable. Then if i go about using user_attributes, in this case i would need to define at the user/group level what are the values for that user_attribute for each and every group or the user. And as customers can move from one region to another and certain ones require access to only specific set of stores in the region they belong to, its going to be cumbersome from a maintenance perspective on maintaining all these different combination of values at the group attribute level. And if i could get the user login information, like in this case kraghunathan-domain name captured in the variable like “user.login” and then join to a table like USER_STORE_ALIGNMENT_DATA_RIGHTS on USER_STORE_ALIGNMENT_DATA_RIGHTS.USER_LOGIN = %user.login%.

I am not sure if {{_user_attributes[“attribute_name”]}} can be used the way i described above unless i am missing something here. As i emphasized its going to be hard managing through values of all different groups based on the hierarchy we have chain-region-division-district-stores with all groups and values for all these different types of groups based on the user logging in.

0 Likes

(Nate Pickens) #8

@kraghunathan There’s a saml_user_id User Attribute that is automatically created and holds the login of the current User when you’re using SAML (or ldap_user_id if you’re using LDAP). That sounds like what you’re looking for.

0 Likes

(Kumaran Raghunathan) #9

so if i understand correctly, i should be able to use saml_user_id or ldap_user_id based on my authentication mode, to use this parameter at the join level like i described above and get what i want, rather than trying to setup it at the user attribute level as this user attribute is created by default.

So are these user_ids automatically created for 3.56 looker version or is this something available only from 4.6 and higher.

The ***user_id you mentioned is what i was looking for as that should help in the solution implementation at the join level that i was thinking on. Additionally what about users are using email mode to login as for certain users we could use email ids instead of using saml authentication mode to login to the application.

Then this should make our life easier. I still got to test it as we have yet to roll out new looker versions but if this is something available in prior looker versions, then i could easily use those parameters in the lookMl code to test it.

0 Likes

(Nate Pickens) #10

@kraghunathan The saml_user_id and ldap_user_id User Attributes are available as of 4.6.

That being said, if what you care about are the users’ email addresses (as opposed to some other kind of ID), just go with the email User Attribute. That gets populated for SAML accounts based on the “Email Attr” setting you specify when you configure SAML (Admin > SAML, “User Attribute Settings” section). And then things will also work for accounts that aren’t being managed by SAML (ones you manually create in Looker).

0 Likes

(Maya Simon) #11

It would be great to have a boolean option for Data Type. This would make it easier to avoid getting the yes/no string wrong somehow.

0 Likes

(Morgan Imel) #12

Hey Maya,
Can you elaborate about the challenges you’re having with the yesno type?

0 Likes

(Maya Simon) #13

Hi @Morgan -

I am looking specifically at the Data Types available when creating a new User Attribute.

There are string, date, and number types available, but yesno/boolean is not an option in the Data Type dropdown on this page.

I’m hacking it by using a string and setting the values to “yes” or “no” – but this means that when someone else is developing in the model and using this as a column-level filter, they have to match the string exactly. There’s just more room for human error. Having an actual yesno type would reduce some of that risk.

Lmk if this doesn’t make sense or if I can clarify further?

Thanks!

0 Likes

(Morgan Imel) #14

Thanks Maya, I initially misunderstood but your clarification helps. I’ll pass your feedback along to the product team on this!

1 Like