Hortonworks: How to Manage Users - kerberos

I am new to Hadoop management and Hortonworks Hadoop. My question is what is the common practice of managing users in Hortonworks. Ambari allows me to create users, but how do companies map users in Ambari to their users. I see that in Hortonworks, I can enable Kerberos; is this the way to allow company users, for example in LDAP, to use the same username/password to login to Hortonworks? I'm not looking for details here, but just some guidance as to what the common practice is.

An identity source is needed. AD is quite common to be used for that purpose. You'd use something like sssd to integrate AD with your cluster nodes. Once that is done, you can integrate your cluster with AD's kerberos. Finally, you'd use AD's LDAP as a source of authentication for Ambari.
Of course, neither of those things is required. You could as well maintain various identity sources and sync periodically between them (e.g. OS users in /etc/shadow, kerberos users in MIT KDCs database, Ambari users in relational database, etc). Just take into account extra time/effort that will be needed to manage cluster users.

#facha gives a nice explanation.
Since I work with LDAP and Hortonworks I can only comment on this combination. To start figuring some things out you can for example use LDAP (called demo LDAP) that comes with the standard installation of Hortonworks. You can use the pre-supplied LDAP mappings in Ambari to add more users.
Afterwards you can import these users in Ranger for example to set new policies for the different Hadoop services. This is done with "ranger user sync", which is different from the access to Ambari with ldap users (ambari-server sync-ldap). I was not aware of this difference in the beginning, so it is good to notice.
If you have done all this you can also add Kerberos security, but this is something a lot more difficult to understand (keytabs and principals etc.).
Here is some good information and a nice tutorial on working with LDAP.
If you want to easily manage LDAP users and groups, I would recommend ApacheDirectoryStudio.

Related

Emulating tenants using roles

We are developing a keycloak(5.0.0) based solution where our clients can create their account with us and manage their own users - and only their users.
Initially with thought that we could use realms for this. Every client gets their own realm. After initial testing we deemed it might not be a good solution as after creating ~500 realms the application becomes unresponsive(https://issues.jboss.org/browse/KEYCLOAK-4593).
We decided to try using Groups to emulate a tenant. Our objective is to create during an external process(keycloak REST API) a group with an admin user.
Can't find currently a way how to restrict this administrator to be able to only manage their own group(creating subgroups, managing users, and giving them roles).
I've noticed several emails mentioning these features but I fail to find actual examples to make this work.
http://lists.jboss.org/pipermail/keycloak-user/2017-June/010882.html
http://lists.jboss.org/pipermail/keycloak-dev/2017-June/009496.html
The second link shows exactly what we would like to achieve.
Current alternative I can see is to implement a facade(client or separate web app) which would restrict visibility and access to other groups.
Are there other alternatives?

Role Based Access Authorization in perfect

Being new to perfect server side swift, I cannot find any packages that help with role based access authorization. In Spring there is for example,
.antMatchers("/homePage").access("hasRole('ROLE_USER') or hasRole('ROLE_ADMIN')")
.antMatchers("/adminPage").access("hasRole('ROLE_ADMIN')")
Is there something already existing in perfect to help with this? Is there a recommended way of handling access control in perfect?
As you use perfect server, you may take a look at:
PerfectlySoft Perfect-Authentication
perfect.org authentication
perfect.org Turnstile
Perfect provides system level of authentication.
Firstly, you can go to github and search PerfectlySoft/Perfect-LocalAuthentication for user identity validation, however, it doesn't contain the role control as you asked.
It can be done in other approaches. For example, you can use Perfect-LDAP to access an LDAP server for all kinds of roles and groups.

Single sign on solution

Hi I am using CAS for SSO. But problem is that i want reset password,register new user on CAS login screen.Does CAS provide these services or i have to implement?
Or Any other SSO solution exist which fulfill my requirement.
CAS is just a SSO frontend to your existing identity management solution (database, LDAP etc). It does not include any identity management features itself (create user account, reset password etc). I have recently been using the Cloudseal platform which is a full identity management solution and so far I am pretty impressed. I believe Atlassians Crowd also includes this although I have not used it. There are probably other products out there as well.
Both of these are commercial products although they are both free for the first 50 users. Crowd is a traditional standalone platform which you download, install and configure but Cloudseal is a hosted service so there is no installation and less config.
You can certainly modify the spring weblog and login page to allow for the functionality that of course you'd have to implement. You should also ask the question on #cas-user mailing list to see if a similar need in the community has been implemented by other users which you may be able to take advantage of. I remember only recently someone raised the same question to the list and there was a bit of interest in getting this feature developed and integrated. You may want to revisit the topic on the mailing list.
Hope this helps.

IBM Portal Database and Authentication

I have a couple of questions regarding IBM Portal Portlets.
I have just stumbled into the realm of Portlets - and as far as I am concerned was dropped into the deep end. Having to work on a IBM WebSphere Portal 6.1
We are still in the evaluation stage - and three things that I haven't been able to find clear answers to yet.
Database - is there one single Database that also gets used by the installed Portlets - or do you configure DB individually on a per Portlet Basis?
Authorization and Authentication - how can a Portlet get hold of the User and the rights the user has?
Are there any known constraints in using JSR-301 compliant JSF Bridges instead of bog standard Portlets?
Thanks in advanced.
I haven't used Portal 7 yet, but I have used pretty much every other version, so my apologies if you are using 7 and this information doesn't fit exactly.
1) Database: when you install portal, you configure a database it uses to store portal configuration (and sometimes user rights as well, although this aspect can be set up using a custom user registry like LDAP). If you don't have an already dedicated DB, Portal will use its packaged DB, Cloudscape/Derby. This DB can be completely separate from the DB that the portlets use to manipulate data unrelated to configuration. E.g. if your portlet is displaying inventory for a bike shop, the DB holding that info can be accessed in the normal web application way through a datasource set up in the WAS GUI.
2) For a lot of scenarios, your portlet doesn't need to know the user's rights, it won't render the portlet unless the user has been assigned the correct rights via Portal Administration. But in the cases in which you would need to know the user's rights, they can be accessed via the Portal User Management Architecture. Here's a good whitepaper on the subject: http://public.dhe.ibm.com/software/dw/websphere/PUMA_scenarios.pdf
3) Known constraints? You may have to google for that specifically, but I will say that unless you use IBM's custom JSF bridge, there may not be a lot of support from IBM's technical issue team if you come up against a problem. However, the support guys are usually pretty helpful, I find. Don't let that stop you from trying though :)
The two resources that I use pretty exhaustively are the InfoCenter http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp and the developer forums on IBM Developerworks.
Best of luck, and welcome to the dark side!

Minimum overhead for ASP.NET MVC authentication

I want to keep things as simple as possible and I don't want a complicated security mechanism. Basically I need for a user an ID and an e-mail address and I really don't want to bother about other things. Also, I was a minimum overhead in terms of security (if there is anoter provider who can do it for me, that's even better).
What is the simplest way to do this? I was thinking about incorporating LiveID or OpenID by I don't know what are the advantages/disadvantages.
I am working with the Azure SDK.
If you use the Windows Azure Access Control Service, you can basically outsource all identity management. Take a look at the Windows Azure Platform Training Kit - there's a lab called "Introduction to the AppFabric Access Control Service 2.0" that will get you up and running quickly. Currently, you can choose any combination of the following identity providers:
WS-Federation
Facebook
Windows Live ID
Google
Yahoo!
"Simple" for whom?
The simplest strategy for you would probably be to use ASP.NET's standard SQL-based authentication provider. You just run a script against your database to set up all the tables, and then you use ASP.NET's built-in utility methods to authenticate. Give your user-specific tables a foreign key reference to that user's ID, and you're good to go. We've done this, and never had any trouble with it. It's a tried and well-used system, so you know you won't be introducing any security invulnerabilities by hacking your own solution together. (see SqlMembershipProvider vs a custom solutions)
If you want something simple for the user, then an OpenId solution would be my pick. Set up something like StackOverflow has, where you can let users choose an account from a number of trusted providers to allow them to log in. From the user's perspective, it's really nice not to have to remember one more username and password for one more site.