Default Landing Page for Authenticated but Unmapped Users
We have a considerable number of users who are able to authenticate via upstream corporate AD server, but fall through the role mapping process. Our default role used to be a Catalog, but we decided that allowing these fall-thru-the-crack users into Morpheus and allowing them to see or launch anything is a security risk. Now, for users who can come in through corporate authentication but are not in a group we have provisioned aforehand, we are setting them in an extremely restricted role, and rather than the user being presented with User Settings in this circumstance, we would like to push them to a customizable, informative landing page allowing them to understand why they can’t see or do anything, and who to contact to resolve the issue (which could be setting their role manually, or getting their group provisioned, or perhaps getting their group set correctly in AD).
(Replace with mock workflow/example/diagram when applicable)
Going through ideas. Have you looked at setting a required group on your IDM? This would prevent those without access from even being able to authenticate to Morpheus.
Well, the issue is that we don’t want anyone who has not properly onboarded and reserved/paid for resources, on this system. So you have all of these business units within Cox, and even within our own business unit (Cox Communications), we don’t want just any Tom/Dick/Harry logging into Morpheus. It is pretty much group by group by group coming in here, and we have to set each group up depending on what images they want to run, what vCenter clouds they want to connect to, and what features they want to see and use. Because the AD administration is a big bureaucratic thing, there isn’t a way to have some required AD group that you would knock everyone into - that we could easily maintain. Really, the existing situation of mapping people with the AD groups seems to only be working about half to 3/4 of the time. I see a lot of users coming in that I need to manually assign to roles.
So if you enable
Required Group +
Include Member Groups you end up with what I think you’re trying to achieve. You would create a group, say “Morpheus” and nest the other groups inside of that. You will still map those nested groups to roles on the right hand side. However, only members directly in the required group or sub groups will ever be able to authenticate to Morpheus.
Yeah, that is an option and maybe we should do that. I have been, up to now, trying to avoid having to maintain yet another AD group.