RELATED IDEAS
Notebook Security - need a third option to restrict notebooks ONLY to users within our corporate domain
We have a situation where we want to publish high-level road map information to anyone within our company who is interested. Ideally, we'd create the notebook, then publish it and provide that link on a corresponding webpage on out internal intranet.
The problem here is that the only option that I have is to allow everyone in the world to see the notebook OR only Aha! users can see the notebook.
The former doesn't work as technically anyone in the world can access it if they have the link (use case - an employee leaves to join a competitor, thus gaining access to our data). The latter doesn't work either as we'd need to add everyone in the company (in theory) as an Aha! user which is way to much overhead from a user management point of view.
My proposal is for a third option - 'Only employees in company X can access web notebooks'
Access would need to be checked via domain access - ie - if they are on our intranet then they are allowed to view the notebook. (I realize that you may need to enforce this via SSO, and that's fine)
Without this option, I am forced to produce PDF versions of the notebook, which clearly breaks the real-time views of the underlying data.
RELATED - APP-I-1533
-
ADMIN RESPONSEJul 22, 2022
Limiting access to users one a specific network is now possible via IP address access control: https://www.aha.io/support/roadmaps/account/security-and-system-requirements/enable-ip-address-based-access-control
Notebooks bypass the per-product data permissions within Aha!, so content added to a notebook is visible to any user who is granted access to the notebook, regardless of that users own product roles. This is intentional since the point of notebooks is to share data outside your team or company.
Since this idea was created we added IP address based access control which can be used to implement what Joe originally requested. http://support.aha.io/hc/en-us/articles/207924743-Enable-IP-address-based-access-control. Note that this feature is only available in Enterprise+ plans.
To clarify a response from Danny Archer, when you say, "If you are on an enterprise or enterprise+ subscription your SSO can allow users that are part of your identity provider to automatically be created as Aha! users with no access except to access the notebooks they have shared." In this use case you're concerned with the author / sharer of the notebook is no longer with the company, correct?
I'm looking to share a notebook with an internal team only, but these folks aren't Aha users. If I make them Aha users, they see everything. I asked if adding them as users but giving them no permission to products would still let them see notebooks, but was told that the notebooks are smart enough to realize they don't have access to the areas feeding the notebook. Therefore I think we need the "Notebook Only" option that was requested.
Excellent idea. Many of our roadmaps are highly confidential and some middle ground between an 'everyone can seel' or 'totally restricted' will be very useful for adoption.
I would like to add a point here --
Typically the enhanced notebook security is used in conjunction with a SSO implementation. What you are suggesting admittedly would require SSO and as such would accomplish the same thing as enabling enhanced notebook security and SSO.
If you are on an enterprise or enterprise+ subscription your SSO can allow users that are part of your identity provider to automatically be created as Aha! users with no access except to access the notebooks they have shared.
We are in a similar situation - want to provide a high level roadmap to all people within the company, but not give people in the company access to individual products.
The security model of Ideas would be great... if someone is a verified ideas user from our internal domain it would be great to enable them to see certain notebooks.
Chris - True, but that doesn't work in the use case above. We want to display our road map to employees without the PM intervention, so we would need to publish the password, which would be self-defeating.
Also, if someone from our company left for a competitor AND they had the public notebook link, they could keep tabs on our development. Thus the need to authenticate users from within our corporate domain.
Note that another option you could use in this case is to password protect the notebook. You can add a password to a notebook using the gear icon to the far right of the "Generate PDF" button.