I've got Artifactory set up to allow SSO via an OIDC client in Keycloak. Keycloak talks to Active Directory in the background. I've also got the same Active Directory configured within Artifactory. I've also configured Keycloak to provide user groups in the userinfo structure.
What I'm trying to do is to get OAuth users to automatically be added to the imported LDAP groups within Artifactory. I don't mind if this is done via the userinfo structure or via a separate LDAP lookup when a user logs in. However I can't seem to figure out how to achieve this.
I know that Artifactory provides a plugin called synchronizeLdapGroups.groovy, which seems to advertise doing what I need, however it seems like the plugin is not actually taking effect. That is to say, users do not end up with the permissions that being in the LDAP groups would provide.
I've attempted to write a plugin myself to do what I need, but when I make the API call to add the groups to the user, the plugin crashes. It's unclear why at this point.
It seems like others have used the SCIM feature in Artifactory for something akin to this (mostly via SAML rather than OIDC though), however Keycloak doesn't support SCIM out of the box and the SCIM plugin I've tried using has similarly given me no results.
Has anyone done something similar to this, and has a working solution I could follow?
If it's a specific group you want all users to be in you could try:
Under Security - OAuth SSO settings tab - check "Auto Create Users"
Under Identity and Access - Groups - select the specific group and check "Automatically Join New Users To The Group"
I'm guessing you want to automatically sync user-group association between Keycloak and Artifactory. SCIM is what you're looking for but there's a known issue specifically with Keycloak SCIM plugin.
We're looking into the SCIM plugin for Keycloak (can't commit on a specific timeline for a fix but it should be sometime this quarter).
If you only need the association in the UI you could try SAML with "Auto associate groups" set. It won't apply the groups association for APIKey/Token calls but it would work for the UI.
EDIT:
after further investigation github.com/Captain-P-Goldfish/scim-for-keycloak isn't relevant here - it makes keycloak a SCIM client, not a SCIM server. There's no official support of SCIM in keycloak, see issues.redhat.com/browse/KEYCLOAK-2537 . and there's no working plugin for keycloak that makes it a SCIM server that I could find (tried a few, all broken). For now Artifactory can't support SCIM with Keycloak
Related
I’m currently using Keycloak as my SSO and have a working integration with Jenkins.
In Jenkins I have also installed and configured the Role Based Strategy plugin that allows me to limit access within Jenkins based on a users role.
This all works as expected. However, right now I have to manually configure these user roles from the Jenkins UI.
What I would like to do is have client roles in Keycloak map to their respective roles in Jenkins.
I can’t seem to find any documentation or answers on here on how to do this.
Any guidance ?
What is the benefit of implementing Active Directory based Security to servers like Jenkins?
The only benefit I can think is the admin of the sever does not need to add/remove users because user can login themselves using AD credential.
But In my case I do not want to have the whole company access my server. the server is only used by my team. How can I disable the whole company from login in. (case1)
Besides, I want to grant different permissions to different members in my team. The new members get less permission, the experienced team members get more permissions. I believe this is very common. But using Active Directory based Security looks like they get the same permission because they are in the same groups (case2)
So why should I use Active Directory based Security? Can I resolve the above two cases in a server configured with Active Directory based Security?
Some corporate environments make this a security requirement. In said environments they usually have an internal request system where users can request they have their credentials added to an appropriate group for access to Jenkins. This is better than Jenkins own database and having them email you, the Jenkins administrator.
Once AD Authentication is configured in Jenkins and appropriate groups created in AD you can do a one-time setup of those groups with the Role-Based Strategy plugin in Jenkins and define what those groups have authorization to do.
Plan your groups well and it is a function that you will no longer have to worry about.
Warning: Be very careful when switching over from Jenkins own database user authentication to AD authentication. If you don't get the BindDN details just right you can get locked out.
Spring Cloud Data Flow Server (Local) does not have any dynamic way to set up users and roles either through dashboard UI or shell, ie. there is no way to add or delete users with roles while the server is running.
I have been able to get both single user or file based authentication and authorization working but both of them I had to set up the docker-compose.yml file like so:
spring.cloud.dataflow.security.authentication.file.enabled=true
spring.cloud.dataflow.security.authentication.file.users.bob=bobpass, ROLE_MANAGE
spring.cloud.dataflow.security.authentication.file.users.alice=alicepass, ROLE_VIEW, ROLE_CREATE
spring.cloud.dataflow.security.authentication.file.users.hare=harepass, ROLE_VIEW
However, if I have to add new users with roles, I will have to docker-compose down, edit the docker-compose.yml and then do docker-compose up, for the new user authentication authorization to work.
Is there any work around this?
There isn't any other approach to dynamically add/update users and then have it reflect at runtime in SCDF.
However, in SCDF 2.0, we have redesigned/rewritten the security architecture. In this baseline, we rely on Cloud Foundry's UAA component, which is a standalone application that can work in Local, CF or K8s.
Here, you can directly interact with UAA outside of SCDF. You can add, update, and delete users, too. Of course, you can centrally manage the OAuth token-credentials such as remote renewals and revocations. Check out the end-to-end sample demonstration of the new design with SCDF + OAuth + LDAP, all in action.
The recent 2.0 M1 release already include this improvement - see blog. Try it out and let us know if you have any questions/feedback.
UPDATE:
I recently also bumped into a UAA Web-UI from the community. Perhaps UAA team could consider adding it to the official stack eventually.
SCDF Server for Cloudfoundry: 1.2.4.RELEASE
Configuring the security properties for LDAP authentication, and I have the authentication part working, but authorization is proving a little strange.
SCDF's security implementation appears to be looking for some roles like this:
ROLE_CREATE, ROLE_MANAGE, ROLE_VIEW.
But for me, the standard group names require some specific naming convention in AD similar to the following: app_myapplication_authz_CREATE, app_myapplication_authz_MANAGE, and app_myapplication_authz_VIEW
When I debug through the SCDF authentication output, I can see that my authenticated principal's group memberships are being retrieved correctly. They show up in the DEBUG output as: ROLE_APP_MYAPPLICATION_AUTHZ_CREATE, ROLE_APP_MYAPPLICATION_AUTHZ_MANAGE, ROLE_APP_MYAPPLICATION_AUTHZ_VIEW
Now, I include a YML security configuration that looks like this:
spring:
cloud:
dataflow:
security:
authorization:
enabled: true
rules:
- GET /metrics/streams => hasRole('ROLE_APP_MYAPPLICATION_AUTHZ_VIEW')
- POST /apps/** => hasRole('ROLE_APP_MYAPPLICATION_AUTHZ_CREATE')
- etc, etc, etc
And so on, for all the endpoint authorizations.
However, I'm still receiving a message after successful authentication that I don't have the appropriate roles and I need to talk to my administrator.
What am I misconfiguring, or what am I missing in this setup?
Update
I downloaded the source code for the 1.2.1.RELEASE version of the spring cloud dataflow ui from here: GitHub spring-cloud-dataflow-ui
And discovered that in all the .html view files, the role names are hard-coded for ROLE_VIEW, ROLE_CREATE, ROLE_MANAGE. Thus, it looks like my configuration will allow me to customize the authorization on the REST endpoints based on my LDAP group names, but I will not be able to do the same with the actual UI views. I think I have one option here, which would be to build/generate my own custom version of the UI, and bundle that with the spring-cloud-dataflow-server JAR instead of using the OOTB ui.
I'll have to weigh whether I really want to do that.
We don't yet have the direct mapping of LDAP AD Groups <-> SCDF Roles. We haven't had anyone from the community or customers' ask for this integration, though. UAA backed OAuth turns out to be the popular choice in PCF so far.
That said, I created spring-cloud/spring-cloud-dataflow#2084 to track the support for group mapping. It could be trivial to implement it (Group vs. ROLE mapping in YAML and parsing logic in the backend code); I marked it for 1.5, but we may pick it up sooner for the 1.4 release next week.
I'd recommend not venturing into adjusting the UI code directly, though. Too much on the local fork and you'll have to maintain it.
I have currently set up a web-based application, to which I have added an authentication method using oauth2_proxy (with gitlab as authentication provider). What I need to know is if there's way that I can restrict the access to this app using a Gitlab group or something like that? Because as of now - oauth is configured to allow access to any user on gitlab which has a #foor.bar email domain (-email-domain=foo.bar directive on oauth config). However I'm looking to control this method in a more restricted manner, so for instance I will create a group on Gitlab, to which I will add only relevant users & other groups to which access should be granted. Is there a way to do it?
Not sure if it's what you're looking for but regards documentation you could use --authenticated-emails-file param to provide authenticated emails list.