We are using ADFS to allow users to log into Artifactory and basically it works fine. Problem is, that the group memberships aren't recognized. Can anyone tell me what the problem is?
Using Artifactory Pro 5.4.4
ADFS 3.0
XML used to transfer the information to Artifactory (I included the mail attribute as well which works fine)
<Attribute Name="memberOf">
<AttributeValue>CN=some_group_the_user_is_in,OU=...</AttributeValue>
<AttributeValue>CN=my_artifactory_group,OU=..</AttributeValue>
<AttributeValue>CN=some_other_group,OU=...</AttributeValue>
</Attribute>
<Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress">
<AttributeValue>x#y.com</AttributeValue>
</Attribute>
I do not have direct access to the ADFS and I really have no experience with it. The responsible person says he cannot filter the groups to show just the one important in Artifactory, so there is a list of groups and one or two might be used in Artifactory and he also cannot change the attribute name.
SAML Settings in Artifactory are:
Group Attribute: "memberOf"
Email Attribute: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
Else SAML works fine. The users are "just" missing their groups - which in the end makes the whole thing quite useless because each new user has to be assigned by hand which obviously isn't really practical with almost 200 users
Can anyone help?
Ran into the same thing and it took me a while to troubleshoot it.
First of all, you have the SAML settings set up correctly.
What you need to do is to create the group in artifactory with the exact ID as the one specified in your SAML. In your case you will have to create:
CN=some_group_the_user_is_in,OU=...
CN=my_artifactory_group,OU=..
CN=some_other_group,OU=...
I assume these are not the real names of your groups but I copied them verbatim from your question.
Then you'd need to give your groups the proper permissions to be able to browse the proper repositories.
Word of caution, the SAML group association allows the users to browse Artifactory according to their permission. It does not allow them to use that association to access artifactory using a generated token as you would if you want to run a build from a developer machine rather than user the Artifactory password.
The latter missing feature was promised to be delivered in Q4 2018 by their support.
Here is the JIRA issue related to the missing feature.
I also ran into this by setting this up on an Artifactory instance.
As already mentioned the SAML SSO synchronizes the groups of a user only on the ui interface and only in the background.
This means a user is not added to the group he is assigned to in the identity provider.
JFrog provided now an SCIM feature which is only available to the Enterprise edition (as of 2021-06-16) of their JFrog Platform.
This feature works like SAML SSO but also synchronizes the groups of an user so it can also be used via API which means during build time of an developer machine.
Related
Let's say we have a lot of projects. Project1, Project2, etc. and let's say their local development domains are example1.local and example2.local, etc.
Now we have set up a Keycloak instance of our development machine, with a Development realm inside it, with an AdminPanel client in that realm, and we want to use it for all of our projects.
We can manually add https://example1.local/* and https://example2.local/* etc. to valid redirect URLs and web origins.
But this means that we need to add each and every project we have and we do many many projects per year.
We tried https://* but it did not let us login complaining about invalid redirect_uri.
Is it possible to whitelist every domain for Keycloak?
You should be able to do that. I suggest to check your configuration again. Something like this works perfectly for my scenario which is the same as yours. The only difference is that I created a dedicated client for my applications, but still it's single client for many dev environments:
Valid Redirect URIs: https://* or https://*.local
Web Origin: *
Don't put anything extra for Web Origin. Just the * but this is only needed for example if you want to use a swagger-ui hosted on somewhere else. It allows swagger from any domain ask for token from the Keycloak. If you don't put the *, due to CORS error, the swagger-ui or any tools like that would not be able to fetch token.
It's a minor thing, but worth mentioning that you put https:// in the config, so the client app should also be accessed using https. If someone type http by mistake, the same error would be returned.
We tried https://* but it did not let us login complaining about
invalid redirect_uri.
Unless you are working in a testing environment, or you want to get hacked, DO NOT DO THIS in a production environment. From OAuth 2.0 Security Best Current Practice you read an explanation of a an exploit based on this misconfiguration.
Therefore, you should make your registered redirect URIs as specific as feasible, and simply using a wildcard in a big no-no.
But this means that we need to add each and every project we have and
we do many many projects per year.
Wouldn't it be possible to automatize this via scripts or so? Get the project names and then call the Keycloak Admin API to add those redirectURIs to the client?!
I wanted to capture user attributes coming from SAP IDP(Identity & Authentication tenant service like department,salutation ,company etc ,via UserAccessor SDK api,but although those attributes are set and has value in IDP user and all the integration with IDP and sub account is in place post authentication ,user attributes object is empty ,i am only able to retrieve specific attributes like first names ,last name,email address ,user groups etc via JWT and UserAccessor api ,but no luck with other attributes ,in IDP i have mentioned these attributes as well under assertion attributes in SAP Identity authentication tenant .
Please guide and help in this matter .
Thanks Siddharth
Update: As we have now identified the problem, I will update my answer to reflect that. The original answer below is outdated:
Okay so the problem is that you haven't mapped any additional user attributes from your Identity Provider (IdP) to your JWT. As far as I'm aware there are three things you will need to do:
You need to create attributes in your xs-security.json (the file you used to configure your XSUAA service instance). This documentation should explain how to do that.
You need to configure which attributes are exposed by your IdP (in your case the SAP Identity & Authentication service. This documentation looks like a good place to start looking).
You need to map the attributes exposed by your IdP to the attributes defined in your xs-security.json. You will probably need to reconfigure (i.e. delete, recreate and rebind) your XSUAA service instance with the updated config, before you can do this step. Then, navigate to your application in the Cloud Platform Cockpit, from the left toolbar click "Security > Roles" and create your mapping.
Let me know if this works for you!
Original Answer:
As far as I'm aware the default IdP does not support SAML. Without SAML, I'm not sure whether you can propagate any attributes from your IdP into the JWT.
Please also check out this discussion for more information.
I'm using .NET 4.5 with a MVC5 5.2.2 web site and a Web API 2.2 service. The web site is using Identity 2.0, and I'm using MachineKey as a data protection provider. In the web site, I'm able to create new users, generate an email confirmation token and then verify that token when it comes back.
In the web service, I need to follow the same process - create a new user, generate email confirmation token and email that token to the new user. The user should then be able to visit the site, confirm the email address and finish creating the account. The problem I'm having is the email confirmation tokens generated by the web service can't be verified by the web site.
Both the service and the site are on the same machine. I can also duplicate this on my local machine in Visual Studio. My first guess was the machine keys weren't the same, but changing both sites to use the same hasn't worked. I've tried and confirmed:
Both sites have <httpRuntime targetFramework="4.5"/> in the <system.web> section.
I've tried <machineKey compatibilityMode="Framework45"/> in both sites.
I've tried generating machine keys - using decryption=AES and validation=SHA1 - with and without setting compatibilityMode.
Per https://aspnetidentity.codeplex.com/workitem/2439, I tried capturing the data protection provider and using that instead of MachineKey.
What am I missing?
So my first lesson from yesterday is that it is best to play Russian roulette with as few bullets in the chamber as possible. Otherwise you end up with a sore foot...as well as a sore forehead.
My problem ended up being that while I knew the confirmation tokens were being url encoded correctly from the site since I was using UrlHelper, I was forgetting the service was not using UrlHelper which mean those tokens were not being encoded correctly. After fixing that, I was able to figure out the machinekey settings.
For anyone who finds this, if you need to share Identity 2.0 tokens between different sites, I can confirm that you need a common machinekey set in your web.config for each site. I wasn't able to figure out if a common machinekey can be configured in IIS Express, so I ended up putting the keys in the web.config in source control then using the config transforms to remove them to make sure they aren't included when the site is published. In production, I'm going to use IIS to set these keys for the default web site so they are shared across both sites.
I am trying to use JASIG CAS as SSO for several webapps. I've managed to setup a custom configuration (maven overlay) and "casify" a couple of webapps. Nevertheless, I'd like to add some monitoring functions such as:
List authenticated users: IP, principal identity
Expire a session user
List which applications is the user signed on
Is there anything similar to this in JASIG CAS out of the box?
Any help would be really appreciated.
Thanks very much
You didn't mention the CAS version you are using, this answer covers version 4.1.
I think the closest thing out of the box is:
SSO Sessions Report
CAS also provides a /statistics/ssosessions endpoint that produces a report of all active non-expired SSO sessions. The output of this endpoint is a JSON representation of SSO sessions that is rendered into a modest visualization.
By default, ticket-granting ticket ids are not shown. This behavior can be controlled via cas.properties:
##
# Reports
#
# Setting to whether include the ticket granting ticket id in the report
# sso.sessions.include.tgt=false
Link:
http://jasig.github.io/cas/4.1.x/installation/Monitoring-Statistics.html#sso-sessions-report
A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html