Qlik Community

Qlik Design Blog

All about product and Qlik solutions: scripting, data modeling, visual design, extensions, best practices, etc.

Employee
Employee

Today - Jeff Goldberg is back and will introduce us to using session attributes to pass security and other information to a Qlik Sense session.


Introduction

Did you know with Qlik Sense security rules, it's possible to use attributes delivered to Qlik Sense Enterprise during the authentication process?  Yup, it's true. While the conventional approach to using attributes is to import them using a User Directory Connector, session attributes are a flexible alternative to storing attributes in the repository to control capabilities and authorization in Qlik Sense Enterprise.

Qlik Sense supports session attributes through SAML, ticketing, and session authentication schemes.  Session attributes are attributes sent in the request for access to the Qlik Sense server.  The attributes are not stored in the repository, but in the user's Qlik Sense session.  Session attributes can be referenced in security rules using the user.environment (e.g. user.environment.attributename) syntax.  In addition, if there is an attribute named group sent to Qlik Sense using SAML, ticketing, or session, it can be used in Section Access data reduction.

Session Attributes in SAML

When you setup a SAML virtual proxy in Qlik Sense, there is an additional attributes section where you can add attribute names from the saml response sent by the identity provider, and the name you want to use in Qlik Sense.  Here you can see I have a SAML integration with Okta.  I have an additional attribute that comes in from Okta named Groups.  In Qlik Sense I have it use the name group.  The name on the left must match what is sent by the idp.  The name on the right can be whatever you want it to be.

jeff1.png

How do you identify the names of the attributes contained in the SAML response?  I use SAML Message Decoder chrome extension.  It's a great tool for reading through the messages sent to an IDP and sent to the Qlik Sense server.

jeff2.png

<?xml version="1.0" encoding="UTF-8"?>

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"

        Destination="https://gss.qlikpoc.com:443/okta/samlauthn/"

        ID="id1026813850591869499238360"

        InResponseTo="_583b079d-39d2-44ab-9824-1336e628770e"

        IssueInstant="2016-12-13T14:03:23.898Z"

        Version="2.0"

        xmlns:xs="http://www.w3.org/2001/XMLSchema">

<...>

    <saml2 :AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

      <saml2 :Attribute Name="email"

             NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

        <saml2 :AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema"

               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

               xsi:type="xs:string">goldbergjeffrey@yahoo.com</saml2:AttributeValue>

      </saml2:Attribute>

          <saml2 :Attribute Name="groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">

          <saml2 :AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:type="xs:string">QlikGroup</saml2:AttributeValue>

          <saml2 :AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:type="xs:string">Everyone</saml2:AttributeValue>

        </saml2:Attribute>

    </saml2:AttributeStatement>

</saml2p:Response>

In Qlik Sense, I've created a stream for members of the QlikGroup group to access in the Qlik Sense Hub. The security rule I put in place uses the user.environment.group attribute and evaluates it against the QlikGroup group value.

jeff3.png

When I log into Qlik Sense,  you see that I have access to the stream I created because in my SAML response I am a member of the QlikGroup group.

jeff4.png

Session Attributes in Ticketing and Session

When ticketing and session authentication schemes are used session attributes are sent as part of the request. Here is a snippet from some sample code that demonstrates how to send attributes in a ticketing request. Notice that in the JSON message there is the UserDirectory and UserId properties and then the attributes property which is an array inside you specify an additional JSON object for each key value pair that's used to send an attribute to Qlik Sense.

ticket request message body

{...}

//The body message sent to the Qlik Sense Proxy api will add the session to Qlik Sense for authentication

string body = "{ 'UserId':'" + user + "','UserDirectory':'" + userdirectory +"',";

    body+= "'Attributes': [{"group":"QlikGroup"},{"group":"Sales"}],";

    body+= "}";

byte[] bodyBytes = Encoding.UTF8.GetBytes(body);

{...}

Once a session attribute has been sent through the ticketing or session request system those attributes are stored for the duration of the users access and are used for security rules just like in the SAML example. Let's take a quick at how this works. I'll navigate to my webpage that uses the ticketing code.  Inside the ticketing code I've supplied a group attribute that will grant me access to the QlikGroup stream. During authentication, security rules will evaluate and determine that I have a group attribute and the security rule uses user.environment.group to grant me access to the QlikGroup stream.

Section Access


In the previous examples I sent along an attribute named group. In reality I could send any attribute I want through the session attributes mechanism. But the group attribute name has some additional capabilities within Qlik Sense. Using the group attribute name allows those values to pass into an application for section access data reduction purposes.

Let's go ahead and open up a sales application as Anne Foster.

Her data is reduced to only the United States because the session attribute named group has a value of "SalesUS".

jeff567.png

When I log in as Eddie Reese, he is only able to see Australia because his the session attribute value for him is "SalesAUS".

jeff8910.png

Wrap up

Session attributes are a powerful and flexible alternative to user directory connectors when using SAML, ticketing, or session authentication schemes.  Session attributes are accessible in security rules with the user.environment syntax, and when the session attribute is named "group", the values may be used with Section Access data reduction.  To learn more Qlik products and discover additional technical materials, join the conversation on our Qlik Community, Qlik Help YouTube channel and view the video libraries on the Qlik Community: New to Qlik Sense Videos - New to QlikView Videos

About Jeff:

IMG_2582.JPG

Jeff is a Principal Enterprise Architect on the North America Enterprise Architecture team who has worked in various technology positions for over 16 years. Jeff focuses on integration, deployment, automation, security, and api topics across a wide range of software. Thanks for this valuable contribution Jeff!





(Hey Jeff - this pic is going to give me nightmares!)


Follow us:
Jeff Goldberg (@goldbergjeffrey) | Twitter

Mike Tarallo (@mtarallo) | Twitter




10 Comments
Luminary
Luminary

I see the value-add of the additional attributes and it's great they can be utilized for Security Rules as well as Section Access - it supports the value proposition of Qlik Sense, that it comes with everything you need out the box (Data Connectivity, Data Modelling, Governance, Visuals).

However, one thing that was not discussed in this blog is how maintenance or governance of those attributes will work. How do I know which users have the session attribute SalesUS? How do I know what the SalesUS session attribute has access to  in terms of apps & data? I don't think that's possible to find out on the current audit page which raises a big red flag to governance and audit.

To conclude, it sounds like a cool feature, but I would still always recommend to everyone to go with classic ADGroups to manage security, which can then also be used to drive permission to other related apps & platforms.

3,827 Views
Not applicable

Hi Martin, With session attributes, maintenance and governance of the session attributes is on the source system, similar to using AD for UDC or any other UDC type for importing attributes.

You are correct that the QMC is blind to session attributes making auditing a challenge, but still a possibility if you review your security rules and identify where user.environment.%attribute% is used.

UDCs are convenient, no doubt about that.  However, there are a number of use cases where a UDC is not possible or undesired.  The goal of this blog post is to raise awareness of Qlik Sense capability to leverage session attributes for authorization and section access. jg

0 Likes
3,827 Views
Luminary
Luminary

I appreciate the value-add of session attributes as well as the intention to raise awareness - however, a credible and proper technical blog should also elaborate on the downsides and challenges of the feature. People read these blogs and understand them as best practices, and sometimes even implement them blindly, if they are published and endorsed by someone like yourself.

0 Likes
3,827 Views
Contributor II
Contributor II

Hi Mike,

 

I tried the steps you mentioned. But, was unable to find the user.environment.<AttributeName> in security rule drop down. am i missing someting ?

3,706 Views
Partner
Partner

similar to SAML auth, I've setup JWT auth for Qlik Sense Virtual proxy and mapped the jwt attribute with Sense attribute, I am wondering if it's possible to store jwt attribute to the local storage in browser from the Qlik Sense hub.js

0 Likes
3,135 Views
Employee
Employee

Does it work with Azure AD?  Azure AD always returning GUID [not friendly name] for user group.

https://support.qlik.com/articles/000066401

0 Likes
2,259 Views