What I have done
First, I cloned the repository of the CAS project from github and switched to the tag v4.2.7.
git clone https://github.com/apereo/cas.git
git checkout v4.2.7
Then I build using gradlew tool
./gradlew
Finally, I copied the artifact ./cas-server-webapp/build/libs/cas-server-webapp-4.2.7.war, and extract it to run, it just works well.
But since I want to configure the CAS using the X.509 Authentication method, the result is frustrated, because the login web flow XML file is different: all of solutions to using a X.509 Authentication method say first to substitute the generateLoginTicket with startAuthenticate like this: https://wiki.jasig.org/display/CASUM/X.509+Certificates, but the "generateLoginTicket" is gone in the file /WEB-INF/webflow/login/login.xml of the version 4.2.7. And the documentation of the CAS is also of no help, https://apereo.github.io/cas/4.2.x/installation/X509-Authentication.html
I want to study how to configure the CAS v4.2.7 using a X.509 Authentication method. I would be appreciate if you could help me out.
As per my personal experience with 5.0 version overlay add to pom.xml
<dependency>
<groupId>org.apereo.cas</groupId>
<artifactId>cas-server-support-x509-webflow</artifactId>
<version>${cas.version}</version>
</dependency>
And add proper CA certificates to the server keystore.
Related
We've been having some issues getting Fastlane Match to work in Gitlab CI using access tokens from within an existing CI pipeline.
The setup:
Repo for storing the certs / profiles: set up during fastlane init. We'll call this the "Cert Repo".
Repo for our React Native project: uses fastlane to handle builds/uploading to App Center and Testflight. We'll call this the "Project Repo"
Setup of match via match init went fine. We did the setup via terminal on the build server.
In our Matchfile:
gitlab_project("PATH_TO_CERT_REPO_HERE")
storage_mode("gitlab_secure_files")
app_identifier(["APP_IDENTIFIER_HERE"])
username("APPLE_ACCOUNT_USERNAME_HERE")
keychain_password("KEYCHAIN_PW_HERE")
team_id("TEAM_ID_HERE")
We had to pass in some env vars to the command for our gitlab enterprise api url (as "CI_API_V4_URL" and the Cert Repo access token as "PRIVATE_TOKEN"
We ran match for all cert/profile types we needed and they all uploaded to the secure files section of the Cert Repo correctly.
The Problem:
Our branches in the Project Repo use Gitlab CI to run various scripts and call a fastlane lane that will do the versioning, certs/profiles, and then upload the build to App Center or Testflight.
When we run match in readonly mode in our lane this way, match is failing with a 401 error.
Looking into the source for match and secure files for storage, it seems if you have a PRIVATE_TOKEN env var set, match will give a warning that you have both JOB_TOKEN and PRIVATE_TOKEN set and it will use the JOB_TOKEN.
The JOB_TOKEN is provided via Gitlab CI itself.
My guess is the JOB_TOKEN for this pipeline is not a valid token to authenticate against the CERT_REPO, which match needs to download the certs/profiles.
How is this supposed to work if I can't pass in a token for match to use for the CERT_REPO?
If we were using normal git storage, you can pass in the git_basic_authorization argument and give the base64 encoded "username:acces_token" string, which I'm assuming would solve the problem.
But using gitlab_secure_files, you can only use tokens.
Before we go and redo everything to use git storage and not gitlab secure files, can someone explain what we're missing here?
How is match supposed to authenticate with the Cert Repo from within the Project Repo in CI if the token it has is for the Project Repo? Doesn't it need the token for the Cert Repo to authenticate?
Some pointers more than anything required here.
I'm trying to get both X509 and LDAP working in my application. I want users to be authenticated using their PKI certs and then for the APP to get their authorities from our LDAP server.
I have LDAP working with a customer userDetailsContextMapper at the moment however how to add the x509 properly stumps me a little.
I think what I want is a PreAuthenticatedAuthenticationProvider that uses an injected ldapUserDetails service.
How can I do that? Do I need a UserDetailsByNameServiceWrapper to wrap the LdapUserDetailsService up to be used within the pre-authentication provider?
I ask because unfortunately the testing platform and the development environment at the moment is detached, and I don't have local LDAP or PKI set up to test against so its about a 6 hour process getting a new war onto the dev environment... Restrictive I know... So I want to get it right first time.
Cheers!
NOTE: THE FOLLOWING WORKS WITH Spring-Security-Core v1.2.7.3, Configuration names are different in 2.0RC2
Following a few different ideas, this is what I came up with. This assumes you already have LDAP working with a custom and UserDetailsContextMapper (see: ldap documentation):
Ensure both the LDAP and a PreAuthenticatedAuthentication Provider are in the provider list:
grails.plugins.springsecurity.providerNames = [
'preAuthenticatedAutehnticationProvider',
'ldapAuthProvider',
'daoAutehnticationProvider',
'anonymousAuthenticationProvider',
'rememberMeAuthenticationProvider']
Then in your spring resources (grails-app/conf/spring/resources.groovy) configure the following beans:
ldapUserDetailsService(org.springframework.security.ldap.userdetails.LdapUserDetailsService,
ref('ldapUserSearch'),
ref('ldapAuthoritiesPopulator')) {
userDetailsMapper = ref('ldapUserDetailsMapper')
}
userDetailsByNameServiceWrapper(org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper) {
userDetailsService = ref('ldapUserDetailsService')
}
preAuthenticatedAuthenticationProvider(org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider) {
preAuthenticatedUserDetailsService = ref('userDetailsByNameServiceWrapper')
}
And bobs your uncle and you have some aunts!
For reference the pages I used to come up with this solution are:
No AuthenticationProvider found using spring security
Wrap your LdapUserDetailsService in a UserDetailsByNameServiceWrapper
Instead of the LdapAuthenticationProvider configure a PreAuthenticatedAuthenticationProvider that will be able to process the PreAuthenticatedAuthenticationToken issued by your CustomX509AuthenticationFilter.
Inject the wrapped LdapUserDetailsService into the PreAuthenticatedAuthenticationProvider.
http://blog.serindu.com/2011/05/26/grails-spring-security-using-preauthenticated-authentication-provider/
Covers how to wire up a preAuthenticationAuthenticationProvider in grails
http://forum.spring.io/forum/spring-projects/security/108467-combine-pre-authentication-with-ldap-for-user-details-and-authorities
there's an LdapUserDetailsService that does all the good things the LdapAuthenticationProvider does - except for authentication
http://pwu-developer.blogspot.co.uk/2012/02/grails-security-with-cas-and-ldap.html more on how to wire up that ldapUserDetailsService
Hope this helps someone else!
we want to integrate CAS authentication into Sonar 3.7 LTS. We want to start working with the deprecated CAS plugin, which of course doesn't work. We already compared it with the LDAP plugin from here whose Authenticator interestingly implements the deprecated interface LoginPasswordAuthenticator. One of the main differences is that the CAS Authenticator plugin implements Authenticator. So we altered the CAS Plugin that it implements LoginPasswordAuthenticator instead.
Now comes the clue:
In both cases, the authenticator implementing Authenticator or LoginPasswordAuthenticator, the username passed to it is null. The authentication against the CAS server works like a charm, the plugin knows the username, but Sonar asks the plugin, if it knows the user with the name null. The effect is that when we click on login we get redirected to CAS, fill in the login form and get redirected back to Sonar, still not authenticated to Sonar itself.
We also considered using container authentication but are not sure if that works with Sonar.
Now the question(s):
Has someone got the CAS plugin working with Sonar 3.7? If yes, how and can you provide the sources/solution/plugin?
Is there another way besides the suggested ones above?
One additional note: We want to use Sonar in our existing Tomcat 7, so using Sonar 4 is a way we do not really want to go because the Sonar team decided to stop war support. If anything else fails though, using it is a pain-in-the-ass-but-acceptable solution.
Thanks for your help.
Try this fork: https://github.com/jerzykrlk/sonar-cas.
I restored the behaviour of the original plugin - it should work with Sonar 3.7. It is unofficial at the moment, and will require a manual build. But maybe it will become an official plugin at some point, again.
Thanks to #psqita we got the CAS plugin for Sonar up and running with Saml 1.1. Business requirements said that no anonymous access shall be allowed. Sadly, setting forceAuthentication to true sent us into an endless loop of painful redirecting between CAS and Sonar. So we figured out that Sonar alters its behavior drastically in a way that it ignores all authentication plugins.
Our solution: As of business requirement we could not allow anonymous access. So we implemented another Filter that redirects conditionally to CAS. Authentication and stuff is still done by the plugin. Sadly, we still do not know why there was this endless loop in the first place but now it doesn't happen anymore. Well that's IT I think...
Thank you for your support and happy holidays.
I'm trying to get omniauth-saml configured, but I'm not entirely sure what I need to put in app_id and app_secret for this configuration.
I'm using this gem: https://github.com/PracticallyGreen/omniauth-saml
If I leave those fields blank, of course I get:
Received wrong number of arguments. [nil, nil]
The documentation within the gitlab.yml file links to more documentation about gitlab and omniauth, but that document no longer exists (redirects to old README).
Any assistance would be appreciated, thanks!
https://github.com/gitlabhq/gitlab-public-wiki/wiki/Working-Custom-Omniauth-Provider-Configurations#working-cas-configuration
The working CAS configuration shows you how you skip using the standard configuration and just pass the options directly to the provider using devise.rb. That's how I would configure omniauth-saml as well.
I was able to get SAML working with Gitlab 6.2.4, but it is not the most elegant solution. I am using Okta as the IdP, but I believe the configuration is sufficiently generic and could be applied to any SAML IdP.
Added omniauth-saml to the Gemfile and ran bundle
bundle install --without development test postgres --path vendor/bundle --no-deployment
Created GITLAB/config/initializers/omniauth.rb
Devise.setup do |config|
config.omniauth :saml,
idp_cert_fingerprint: "your IdP certificate fingerprint",
idp_sso_target_url: "your IdP SAML end point"
end
Modified GITLAB/app/controllers/omniauth_callbacks_controller.rb (added this following the definition for ldap)
def saml
handle_omniauth
end
I had to manually add the callback for SAML as I was getting the same error as the original poster when I tried to properly define SAML as a provider in gitlab.yml. This is the only way I could get Gitlab to start and authenticate via SAML. This feels very hacky, so there is probably a more elegant way to implement this; however, I could not find an example anywhere.
https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations#working-saml-configuration
I managed to get it to work, so I documented the procedure on the GitLab wiki.
EDIT: It seems like SAML is now supported officially. No Single Logout yet, though… This seems to be an omniauth limitation.
I followed these instructions to host a NuGet Server (version 2.2.2) on our Intranet. It works great as far as listing the packages and retrieving them in VS 2012. But when I create a package using the Nuget Package Explorer and try to publish it I am prompted with a Windows Security dialog prompting for credentials. No matter what credentials I enter it keeps re-prompting me for a user name and password and returns a 401 authentication error. Why is the NuGet server prompting me for Windows credentials and how can I get rid of it? It only does this for publishing and nothing else.
There are one more thing apart from permissions configuration for Packages folder. In my case I have to use URL like
http://<server>/<nuget_virtual_dir>/api/v2/package/
for pushing. It was the only solution in my case.
When you use NuGet push you need to put /api/v2/package after the NuGet server URL (example http://myhost/myNuGetServer/api/v2/package)
If you use the NuGet user interface (NuGet Package Explorer) you need to put just the server url than URL (example http://myhost/myNuGetServer/)
Take care also of apikey configuration in Web.config and use it in NuGet push!
I think a found a solution (at least to my problems):
I gave up to the Nuget problem, and I focused in the ISS 401 error. Then I gave permissions to the user "IIS AppPool\DefaultAppPool" to the app's root (or your AppPool that use the app, in my case "ASP.NET v4.0"). Then it work like charm!.
More info (and good explanation about the problem): ApplicationPoolIdentity in IIS7 401 errors
You may find this SO answer helpful, as it covers how to configure credentials on a publishing workstation (or build server, but in either case it's accurate info.)