[
https://issues.apache.org/jira/browse/KNOX-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241115#comment-15241115
]
Henning Kropp commented on KNOX-537:
------------------------------------
Sure this needs testing. We just found another issue with this patch, because
like this it is not working with authorization. For this to work the groups
need to be put on the current session. Here is how I was able to make it work:
{code}
private final static String SUBJECT_USER_ROLES = "subject.userRoles";
private final static String SUBJECT_USER_GROUPS = "subject.userGroups";
SecurityUtils.getSubject().getSession().setAttribute(SUBJECT_USER_ROLES, roles);
SecurityUtils.getSubject().getSession().setAttribute(SUBJECT_USER_GROUPS,
roles);
{code}
What is the difference between groups and roles?
[~lmccay] the pam configuration really depends on the pam integration you are
using. It can be for example file based, winbind, sssd, vas, centrify, and
more... For the shiro plugin to work you just need to point to one of the files
under {{/etc/pam.d/}} with {{main.pamRealm.service}}
Here is a sample list of the files under {{/etc/pam.d/}}:
{code}
# ll /etc/pam.d/
total 176
abrt-cli-root
chsh
config-util
crond
cups
passwd
password-auth
password-auth-ac
sshd
system-auth
....
{code}
And this for example the first lines of our {{system-auth}} files which we are
using:
This tells pam to first check the file (local auth {{/etc/passwd}}) and then
vas.
{code}
# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_tally2.so deny=10 onerr=fail unlock_time=900
auth sufficient pam_fprintd.so
auth sufficient pam_vas3.so create_homedir get_nonvas_pass
auth requisite pam_vas3.so echo_return
auth sufficient pam_unix.so try_first_pass use_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so
....
{code}
There is no reasonable default value for {{main.pamRealm.service}}, but
{{system-auth}}, {{sshd}}, or {{passwd}} do make sense. But for example
{{passwd}} could be explicitly disabled, for example to prevent users from
changing their passwords over LDAP. Often it is not prevented, but simply not
configured correctly to support it. And this can be the case for all of them.
To test this it would be enough to just add a system user and try if you can
authenticate with that. Mapping and configuring this to LDAP, with winbind,
sssd, vas, centrify, ... is really the job of the system administrator.
> Linux PAM Authentication Provider
> ---------------------------------
>
> Key: KNOX-537
> URL: https://issues.apache.org/jira/browse/KNOX-537
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 0.5.0, 0.6.0, 0.7.0
> Environment: All
> Reporter: Jeffrey E Rodriguez
> Assignee: Jeffrey E Rodriguez
> Labels: knox, pam
> Fix For: Future
>
> Attachments: 0001-knox-537-add-pam-authentication-support.patch
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> OS level PAM security provides great interface for authentication and
> authorization. For example, sssd provides support for manage Active
> Directory nested OU by adjusting ldap_group_nesting_level = 5. Knox
> configuration is configured to interact with LDAP directly, but this has two
> short cominges. First, hgh volume traffic is likely to make too many
> queries to AD without cache. Second, complex logic of LDAP queries can not
> map correctly to UserDnTemplate without adding more ldap specific logic into
> JndiLdapRealm code and parameters.
> Knox can be improved to use PAM to out source complex OS to AD interaction to
> sssd. It is possible to implement a shiro PAM plugin to reduce the complex
> LDAP logic that is starting to accumulate in Knox.
> Looks like there is a least a start for this here.
> https://github.com/plaflamme/shiro-libpam4j
> libpam4j is available via Maven and uses an MIT license
> http://mvnrepository.com/artifact/org.jvnet.libpam4j/libpam4j/1.4
> This might be a great addition to Knox.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
