Auto Register "Reader" Role with SSO
complete
Shawn Humphries
Doc360 REALLY needs support for automatic reader registration for users to meet expectations of a SSO enabled system. Here is our business problem, our Doc360 Okta authorized users that do not have an account in Doc360 aren’t automatically registered with a “reader” role. We have users that change all the time, both added and removed. We need newly added OKTA Authorized Doc360 users to be able to access knowledge base articles if they are authorized to use Doc360.
The whole idea behind SSO is that you don’t have to manager users and two platforms. Also, we will have manage users both in OKTA and Doc360. For first time users of Doc360, they will get a link to the knowledge base but told they don’t have any account. Then that user will have to follow-up with our IT team. It needs to be EASY for our users to get to documentation – that is why we choose your product, so this issue is a big deal to us.
With all the okta integrations I have done in the past, you give a group attribute and the user is automatically added to a group.
Log In
Thiru
complete
Caroline Tabach
Thiru: 1. We added users, this is also a big step forward for us, that automatically they are added.
Now we would like 2 more things
- be able to define more than one reader group for our SSO users.
- If people are removed from OKTA access how to remove them from the Document360, if they leave the company.
Thiru
All,
The feature was released as part of our recent releases in December'22. Request you to try out and let us know your thoughts.
Hector Payo
The same issue at our organisation. The whole point of SSO for internal readers is to simplify access for them.
David Gregory
Thiru Your last item that you merged in (Allow readers to assign themselves to groups when self registering) is very concerning. Self-registration of user groups should be restricted to the domain in which the account is created.
Thiru
David Gregory: While the SSO is enabled, and users can enable this functionality in advanced settings where users can choose reader group and then by default all readers can be taken into this group and would be able to view contents based on the reader group permissions provided. Kindly check and share your thoughts on this.
David Gregory
Thiru: When I read "users can choose reader group", I understand that this is the reader who is choosing the reader group. Unless I am mistaken this is not what is occurring. Thus I'm OK with your current implementation
Thiru
Thiru
Mike McClain
Same issue for our organization. Frequent changes to teams using knowledge base; does not make sense for us to have to manage manually.
Susan Roux
Same issue here, up to 2000 readers that changes regularly. Using this to be the software guide for an internally developed project calculation tool. Cannot implement the knowledge base without this feature
Matt Casey
We have a similar issue at our company, would be great to have this feature. Self registration for SSO users is a MUST have for an SSO enabled projects (specifically reader role)
Shannon Greywalker
Our company uses Azure AD for SSO, both for our own employees and for our customer accounts and their hosted platforms. It would be _superb_ if you could ensure whatever self-register/SSO approach you work out will also work with Azure AD, and can also be somehow email-domain-aware so that a self-registering user from a given email domain will also be associated with the Azure AD SSO config for that email domain.
Currently we're using non-SSO self-registration that is whitelisting only our customer's various email domains, but this is less than ideal because it forces each customer-side user of the KB site to remember and manage a separate password. Meanwhile, they have access to our actual products via their own company's SSO credentials. So it seems a bit "unprofessional" for each user to manage a separate password just for access to our product doc. It also means more administrative overhead on our side, because if a given user forgets their password, we have to manually delete their account (because you don't seem to have a "forgot your password" feature in your non-SSO system yet).
Feel free to reach out if you want more technical detail.
Load More
→