spring-projects / spring-security-kerberos Goto Github PK

Mike Wiesner (Migrated from SES-15) said:

Kerberos/SPNEGO support should also be available on an IBM JVM.

Rishma (Migrated from SES-111) said:

Can we provide patter in <sec:http entry-point-ref="spnegoEntryPoint"> tag. When I gave a pattern, it was not going to the spnegoAuthenticationFilter class.

Migrated from SES-25

Migrated from SES-27

Migrated from SES-21

Tim Kettler (Migrated from SES-92) said:

To fetch roles from AD a UserdetailsService needs to log in to the AD Ldap-Server. Currently, when using one of the Kerberos authenticators one needs to specify credentials in two locations. It would be great when a UserDetailsService implementation could reuse the authentication of the KerberosAuthenticator.

The code implementing this is available here: http://git.springsource.org/~tik/spring-security/tiks-se-security

Currently the unit tests and samples in the repository are broken. If there is interest to integrate this in the kerberos extension I can invest some more time and fix this.

Mike Wiesner (Migrated from SES-1) said:

Adding SPNEGO web application support for Spring Security by using the JAAS Kerberos Login Module from Sun (Sun JVM 6 required)

Muammer Yucel (Migrated from SES-98) said:

Since Base64 has been moved from org.springframework.security.core.codec through org.springframework.security.crypto.codec package, SpnegoAuthenticationProcessingFilter throws NoClassDefFoundError with Spring Security 3.1.0.RC2.

Stack trace can be found below:

java.lang.NoClassDefFoundError: org/springframework/security/core/codec/Base64
at org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:126)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:340)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:80)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:340)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:175)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3684)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2268)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)

Mike Wiesner (Migrated from SES-11) said:

If you have a client running on an kerberized OS (like Windows), the client should automatically fetch the already present login from the OS and acquire a service ticket for your server and sends this as an HTTP Header to server.

The server then just uses the normal setup for a SPNEGO enabled web app.

That means, that one can also write a Client/Server app, without the need that a user has to login and you have a safe and performant way to transport this informatiion to the server.

Goal of this sample would be:

• In windows environment, User will be able to logon to application with Windows Active directory Credential which has been entered during log on to windows. There should not be any ask for userid/password credentials.
• In non-windows environment, User will be presented with a screen to provide Active directory credentials.

It's not yet clear which steps are possible with spring security kerberos module but at least PR's #4 and #5 which just got merged will help to automate some required steps.

Different browsers also makes things hard in terms of some of the built-in auth functionalities may be disabled on default. There's also issue #6 for this.

Also http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html seem to provide some info to help creating this sample.

Chrome needs some extra flags to white list servers, they black list generally because they support NTLM and it’s pretty insecure. Once these were added it started working in Chrome:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --auth-server-whitelist=".sample.local" --auth-negotiate-delegate-whitelist=".sample.local"

Walter Seymore (Migrated from SES-143) said:

Since this module is being used heavily for several years now, can this please be officially released?

Migrated from SES-22

Mike Wiesner (Migrated from SES-6) said:

Create a sample webapp which showcases the use of the SPNEGO authentication module.

James Kirkwood (Migrated from SES-71) said:

We need to do delegated authentication with another kerberos based service. Therefore we need the delegating credentials as provided by the GSSContext after accepting the client token. Would it be possible to store the GSSCredential in the KerberosServiceRequestToken along with the principle?

It looks like the credentials need to be retrieved from the GSSContext in the KerberosValidateAction inner class of the SunJaasKerberosTicketValidator and returned along with the username (string) before the context is disposed.

I have a working version of this I'd be happy to attach (once I've added unit tests etc) if this is an appropriate enhancement.

Mike Wiesner (Migrated from SES-2) said:

Basic pom.xml and directory structure

Harald Radi (Migrated from SES-29) said:

I don't have a clue why this happens, but i get the following NoSuchMethodError on the server and on my dev machine:

java.lang.NoSuchMethodError: org.springframework.security.authentication.AbstractAuthenticationToken.(Ljava/util/List;)V
org.springframework.security.extensions.kerberos.KerberosServiceRequestToken.(KerberosServiceRequestToken.java:69)
org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:114)
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:356)
[...]

I tried M1 and latest subversion together with the 3.0.0.RELEASE version of Spring Security from the Spring Repository.

After changing super(null); to super(Collections.emptyList()); in line 69 the exception was gone.

Harald Radi (Migrated from SES-31) said:

I know you can't do anything about it, see http://bugs.sun.com/view_bug.do?bug_id=6851973 for further reference.

Just to play safe for legal reasons.

Migrated from SES-152

We should be able to do this via MiniKdc

Mike Wiesner (Migrated from SES-12) said:

The log which comes from the SUN JAAS Kerberos module is often not enough information if you encounter problems. There should be more logging during the authentication process to help troubleshooting.

Kenneth DeLong (Migrated from SES-119) said:

Login on Kerberos using Spring Security Kerberos Extension (via Grails Kerberos plugin) fails after upgrade to java 7. We see a GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC)

You can see a larger discussion here: http://stackoverflow.com/questions/13803458/kerberos-broken-after-upgrading-from-java6-to-java7

Eventually we were able to solve this problem, after many days, by patching org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator

String keyTabPath = this.keyTabLocation.getURL().toExternalForm();
String runtimeVersion = System.getProperty("java.version");
if (runtimeVersion.startsWith("1.7")) 
{
      LOG.info("Detected jdk 7. Modifying keytabpath");
      if (keyTabPath != null)
      {
        if (keyTabPath.startsWith("file:")) 
        {
            keyTabPath = keyTabPath.substring(5);
        }
      }
}
LOG.info("KeyTabPath: " + keyTabPath);
LoginConfig loginConfig = new LoginConfig(keyTabPath, this.servicePrincipal,
                this.debug);

Removing the "file:" causes the login to succeed again.

Michal Dvorak (Migrated from SES-63) said:

If I take AbstractAuthenticationProcessingFilter as reference, calls should be done in following order:
sessionStrategy.onAuthentication
SecurityContextHolder.getContext().setAuthentication
successHandler.onAuthenticationSuccess

When setAuthentication is called after successHandler that performs redirect (i.e. SimpleUrlAuthenticationSuccessHandler with alwaysUseDefaultTargetUrl set to true), SecurityContext is saved into session when performing redirect (in SaveContextOnUpdateOrErrorResponseWrapper), and flag is set that context was saved, therefore the newly set context is later thrown away in SecurityContextPersistenceFilter, because it is already "saved" (I know, its a bit complicated, took me a while to debug it).

André Schäfer (Migrated from SES-136) said:

Problem: Browsers that do not Support Kerberos Authentication receive and display an empty page when authentication response is provided by the SpnegoEntryPoint.
This is behavior leaves the user without any information or option to proceed.

The Spring Security solution SEC-1406 with DelegatingAuthenticationEntryPoint requires information within the initial request to decide for a certain behavior. But is not able to create a fallback scenario if the browser doesn't support the authentication method.

One way to solve the problem is to perform a forward after the correct headers have been added to the response. This way it is possible to either provide usefull information in a kind of 401 error page or even present a login form to provide another authentication mechnism.

Harald Radi (Migrated from SES-32) said:

I created wrappers for AuthenticationEntryPoint and AuthenticationProcessingFilter that allow to filter by url and request headers (e.g. User-Agent).

Here is an example config that I think speaks for itself:

<!-- kerberos authentication -->
<beans:bean id="kerberosEntryPoint" class="cc.catalysts.cp.security.authentication.web.FilteredAuthenticationEntryPoint">
    <beans:constructor-arg>
        <beans:bean class="org.springframework.security.extensions.kerberos.web.SpnegoEntryPoint"/>
    </beans:constructor-arg>
    <beans:property name="fallback">
        <beans:bean class="org.springframework.security.web.authentication.LoginUrlAuthenticationEntryPoint">
            <beans:property name="loginFormUrl" value="/login"/>
        </beans:bean>
        </beans:property>
    <beans:property name="includeHeaderMatcher">
        <beans:bean class="cc.catalysts.cp.security.authentication.web.util.RequestHeaderMatcher">
            <beans:constructor-arg value="User-Agent"/>
            <beans:constructor-arg value="MSIE"/>
        </beans:bean>
    </beans:property>
</beans:bean>

<beans:bean id="kerberosAuthenticationProcessingFilter" class="cc.catalysts.cp.security.authentication.web.FilteredAuthenticationProcessingFilter">
    <beans:constructor-arg>
        <beans:bean class="org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter">
            <beans:property name="authenticationManager" ref="authenticationManager"/>
            <beans:property name="failureHandler">
                <beans:bean class="org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler">
                    <beans:property name="defaultFailureUrl" value="/login"/>
                </beans:bean>
            </beans:property>
        </beans:bean>
    </beans:constructor-arg>
    <beans:property name="excludePathMatcher">
        <beans:bean class="cc.catalysts.cp.security.authentication.web.util.UrlPathMatcher">
            <beans:constructor-arg value="/login/**"/>
        </beans:bean>
    </beans:property>
</beans:bean>

If you are on Java 8 compiling fails because of an Xdoclint issue. If you modify the build.gradle file like this then compiling works again:

configure(allprojects) {
    ...
    [compileJava, compileTestJava]*.options*.compilerArgs = ['-Xlint:none']
    
    if (JavaVersion.current().isJava8Compatible()) {
        allprojects {
            tasks.withType(Javadoc) {
                options.addStringOption('Xdoclint:none', '-quiet')
            }
        }
    }

    test.systemProperty("java.awt.headless", "true")
    ...

Harald Radi (Migrated from SES-30) said:

Some logging output in the AuthenticationException catch block for the case that the failureHandler is null would have saved me a lot of time.

Furthermore, is SC_INTERNAL_SERVER_ERROR really the right status to return here, wouldn't be a 403 Forbidden more appropriate? If I see a 500 response I also expect to find a stacktrace in one of my logs.

Mike Wiesner (Migrated from SES-10) said:

As an alternative or a fallback for automatic SPNEGO authentication, we should also provide a server side Kerberos login.

That means, that a user will enter his Kerberos username and password (e.g. your Active Directory username and password) with the normal support Spring Security offers for that (Form, Basic, Digest) and then the server will authenticate this against the Kerberos server (e,g. Active Directory) by acquiring a TGT.

Mike Wiesner (Migrated from SES-9) said:

UserDetailsChecker should be used, to check the UserDetails returned by the UserService if the User is locked and so on.

Also a protected method like additionalAuthenticationChecks() should be present, so that subclasses can make some more checks.

Alejandro Alanis (Migrated from SES-20) said:

since the SpnegoAuthenticationProcessingFilter does not extend the AbstractAuthenticationProcessingFilter, basic workflow events like AuthenticationSuccess- or AuthenticationFailerHandlers are not configurable. Shouldn't this be the case?

It would be easy then to define some handlers according to authentication success or failure without having to implement everything manually.

Xiaodu liu (Migrated from SES-64) said:

The example web application spring-security-kerberos-sample failed in the following envrionments:

1. jdk 1.6.0_22 or 1.6.0_23
2. tomcat 6.0.29
3. Window xp

with the following error:

Negotiate Header was invalid: Negotiate YIIHpQYGKwYBBQUCoIIHmTCCB5WgJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCB2sEggdnYIIHYwYJKoZIhvcSAQICAQBuggdSMIIHTqADAgEFoQMCAQ6iBwMFACAAAACjggZxYYIGbTCCBmmgAwIBBaEYGxZXQU0uV0VTVEVSTkFTU0VULkxPQ0FMojMwMaADAgECoSowKBsESFRUUBsgZGV2d2FyY2gxLndhbS53ZXN0ZXJuYXNzZXQubG9jYWyjggYRMIIGDaADAgEXoQMCAQ6iggX/BIIF+54nsIgnyOHTnF2nD3XHzz51k/sqBht6lMFESs+CDL2SNCiZOD0Iqee03v3aUyzDncMTkXRRw/F2HOHCv1XPoKFhKZwJDTnKkbm7DDSJFok7rsekQqCntt+DObI6umiZU7XDKP4zyMVadrqQ6psJyUfpaGpU9uRHB79voBJaKGIjeDjSU2z7ybfvoxfPckFO905tM5HXjmM2sm5GAG0gY7/qHlCau1ayH0H/Tfly0EOS1B0D6ryue+Ne6VEt7OUOk89tSQM7F3qUqOsKzwuokBWjERX+ytcnc44uVslncQvn4peWPohePWZL7fpsm4w+kdO40oYeEGhZhbpGLCeII7U51y+NxbiCvTiIuc5nnkhESNQtbrmcUmpJIsbxrjr0cdyFua8oDgEQ6LYuRMY7FHKFDIWvTSaiDIoTBbxkh9I9jHatHhHWdi4WlLo1pJe9Ge4szzDAe2uuHrIgTLjuJx8ryRzq8UfFopJjCehRvBO2CQTyNpyxw6fUZGOQht/QS57/4oGGNWwXTUjsIBRJKNe3x4bsasUgvqhepme40zpAsVXYTv6usiRwAGyVmWTsdH3KZ/syTVghVhcsV1ht5bujwawdXlmR16ZpMPkTXv1hBTvmBwxqsvpGOX4+sG5HT5w/mlpKANUnkeE84m0nOvGp+uMbdhpZ9ya3pPg3BKP+lBfLXHNf0zka77uDLw9K0ZzMsd6t62PsatvrZXCdNrQx8XWKLJ4dHPbxdND7UPtQc2ARiGsak9grd8PG378UkQLlHEEVjh97J+iYxLfNIIfHUbuFxQFqIYXheto1OOrDAY1igsRYP9duoo6ZWiCQnKXxSbcnApIQCiq6r2jxKrzNla6l2GKs0cNB2qqV0XlQNTtVOTG/52EuyNadqpXv39WfhZ64mt4PWQ8bVIL/DR2Jp+bmr+1hCaThLy9l/+52qNC5zj9WAS0+NLRd31cIC3hRTyO2JMSvacfu8v7uV9HbK56R2q38rLg+hu7odPSdkQjEZ9hFWD8Ud3cPpKCDNQRlTnoFTajLlayqWWzZQKjU5GPySToJp2HZW1Ra7HgcM5/6qhoJVVOSE+KpOitGYDYrJ8G6tAk0kOzN0ei/jmkAl5eZNV6hF85T6l7c/kEwu3bJ32r/IAMBK2sBO4Z6SK4SOrSsQXoNBJHKDuY1r34AEHIpazt9hl2U1WyEJDFu9jMMU9q/DEkIGD6FzO0yAYhnnnQFCWJJpjmqqGojiIQwz2W8U95FWMbWdQlCdGnXUIQ1Zdd6xVhrfiFsvD4z92RvyZACyopSVPtIVaBGbRC0/KrxZE9HHOPXjv7WZmBwjKmhgryONs1wge2jNn/saOlExhMT4OjKvjYbfyrdR0WRgTZHvluAxaq5XBBE2QufoFWlibidbZMEdMcL7TDf48ZcpREgtGLJBxkaAhzvbX39iKMmDPCANMSUXN6p0wdsmRNNIno7ghzIoYZ5dh5601BYbYtx9l1rU3LQL46/OVqPIET8LIPMFjgGMlNhME/pAUErEwnvAjIhaH9SyAJksQg6FmU64k8W0EomGzjp6vjOfz+WX1s8pZ4ZKYGXRwFWjq9nWP9BwePthhUQhDLzhGNEeScuG8za2gGeNvZgAqWJ1JiPr4cuwrX4iBOiJsYps0XjLLoi/lAtCBmoTk3qPArtXNqUHRI3ZZtA0LfGhnY+la55qPxm6cWY+ioce3rHraxgr0KLlzMEFRYWb5AMqwTIXL59xL/9O5UyCwc5n1Fbd+OGuOnapK7KWSq6cxJU7ObutxGmQ6aRIJD3RNxGiYnBNkoos546QlubmHno507ZVQ9posYrkJoeQXDgSzuIEA2lD81LfRJfdPdARgFIF5yXWmN0NfCwCrw3X1QloX/Ktzo+9lbHRGhaIo9gS17/Ex1+DjKbFWFwNkRRpONV7jbnJ4ZWfuP3TuKzzX0E12jxMSXvcXPA5mIn0EI1t9f5Bg7L6Hfc0KmxWrsnHRgz9zZ1/i8eDmBMVxJlQSPR7WG2EsUAUB2uP8ADC/hR2j3FedcGQBgkhHOEMNSkgcMwgcCgAwIBF6KBuASBtczMFtvZHJDYRG8gUL+HJazLtrNiqjMu/I5CruvOy03uM5l2EOuE3c21lW04O9QHWdC7MCxdOnqRoDt3W+0kD3mBIdjjA0YGVPA1qPD1v8j9UMoAr2fuUYkO5qFsjFZ05u0w8rfi5/jq8FwB2idooBq9hYLGISbIstctr2Gt4W5tdfrCrxdRH2z48y1oqKFwmzQ2N57LJcAYY0cjxb/uRKEv+fk3TlvDF92Ci3JJzmzC+lK8uo4=
org.springframework.security.authentication.BadCredentialsException: Kerberos validation not succesfull
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:69)
at org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider.authenticate(KerberosServiceAuthenticationProvider.java:86)
at org.springframework.security.authentication.ProviderManager.doAuthentication(ProviderManager.java:120)
at org.springframework.security.authentication.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:48)
at org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:131)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:188)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79)
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355)
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149)
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.security.PrivilegedActionException: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:396)
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:67)
... 25 more
Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Specified version of key is not available (44))
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:874)
at sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:541)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:323)
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:146)
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:136)
... 28 more
Caused by: KrbException: Specified version of key is not available (44)
at sun.security.krb5.EncryptionKey.findKey(EncryptionKey.java:527)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:260)
at sun.security.krb5.KrbApReq.(KrbApReq.java:134)
at sun.security.jgss.krb5.InitSecContextToken.(InitSecContextToken.java:79)
at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:724)
... 36 more
SecurityContextHolder now cleared, as request processing completed

It works fine with the older jdk version, for example 1.6.0_18.

Please help.

The latest available maven artifact is from 2010:

http://maven.springframework.org/milestone/org/springframework/security/extensions/spring-security-kerberos-sample/

Please create and publish a release containing the current code. The only artifacts available currently are -SNAPSHOT jars, which are not suitable for use by downstream projects.

• Create spring-security-kerberos-web to limit dependencies for non-web based projects
• Add org.springframework.security.kerberos.authentication to better align with Spring Security packaging
• Add org.springframework.security.kerberos.authentication.sun to isolate Sun implementations of APIs
• Remove unnecessary dependencies

Matthew Tatum (Migrated from SES-54) said:

If a http request is received and it contains an "authorization" header with a negotiate token the SpnegoAuthenticationProcessingFilter automatically overwrites any existing authentication object that is in the context held in the SecurityContextHolder. Could there be an option to ignore any "authorization" headers if a valid autentication object is already present in the SecurityContextHolder.

John Ruiz (Migrated from SES-128) said:

It's been over three years since the release of milestone 2. In that time, there have been a substantial number of fixes, improvements, and upgrades.

Right now, I am operating with a custom-built JAR that contains fixes that have been offered on the JIRA issue comments. (In other words, I can't just use the -CI snapshot version).

I would much prefer to reference a milestone JAR in the SpringSource nexus repository.

Please consider releasing Release Candidate 1.

See StackOverflow

Summary:

After much troubleshooting, it appears to be just bad coding. The keytab file location is supposed to be extracted into a string in afterPropertiesSet() method of SunJaasKbr5LoginConfig. Unfortunately the method never gets called using the stock sample code so even though you pass it the keytab location in the application.yml it never gets processed properly.

Mike Wiesner (Migrated from SES-36) said:

Currently there is only a sample configuration which showcases SPNEGO without any alternative authentication. There should also be sample which demonstrate SPNEGO together with a form based login for user who can't use SPNEGO.

Samples for the new server side Kerberos authentication should also be provided. Standalone and also together with SPNEGO.

Mike Wiesner (Migrated from SES-24) said:

In order to customize the authentication process, SpnegoAuthenticationProcessingFilter should call AuthenticationSuccessHandler and AuthenticationFailureHandler.

miha (Migrated from SES-113) said:

kadmin util does not allow encryption type rc4-hmac.
In consequence in keytab is no record with this encryption type.
Even when adding encryption type rc4-hmac to principle with kadmin it is chnage to arcfour-hmac.

Is it possible to user arcfour-hmac, des-cbc-crc or des-cbc-md5.

It'd be nice if we have a custom RestTemplate which would make it easy to talk to kerberized mvc endpoints.

Mike Wiesner (Migrated from SES-19) said:

The JAAS Kerberos Module, which is used inside, has sometimes problems to load the keytab out of the classpath. Esp. in some Java EE containers like Weblogic and JBoss AS. These containers often don't place the classpath directly in the filesystem, and the JAAS Kerberos Module seems to be unable to load from a classpath which is not directly a filesystem path. Spring Security will for example create a URL like: "zip:C:/xxx/_WL_user/spring-security-kerberos-sample-1/bd3bji/war/WEB-INF/lib/_wl_cls_gen.jar!/s-j-xxx.keytab", and passes this to the JAAS Module as the location for the keytab, but the JAAS module will then fail with the message: "Key for the principal [email protected] not available in ..._wl_cls_gen.jar!/s-j-xxx.keytab".

A solution is, to place the keytab outside of the classpath and specify the direct path in the Spring config, like "file:C:/etc/keytab-test_example_com.keytab". As the keytab is always specific to one host and also needs to have special protection, it shouldn't be placed in the classpath at all.

The JAAS module also seems to have problems when the path contains whitespaces.

Migrated from SES-35

Nikita D (Migrated from SES-55) said:

Spring Security's BasicAuthenticationFilter and UsernamePasswordAuthenticationFilter allow for an AuthenticationDetailsSource bean to be configured. This class is invoked to build the details Object set into the authentication token, just before invoking the authentication manager (see BasicAuthenticationFilter line 136 in 3.1.0.M1).

SpnegoAuthenticationProcessingFilter should provide the same functionality, since this is extremely useful for passing additional metadata about the request to authentication event listeners.

Brice (Migrated from SES-127) said:

When a problem occurs during authentication step, the filter sets 500 error code to the response (cf. https://github.com/SpringSource/spring-security-kerberos/blob/master/spring-security-kerberos-core/src/main/java/org/springframework/security/extensions/kerberos/web/SpnegoAuthenticationProcessingFilter.java#L164 ) which sounds weird for a caught AuthenticationException because it's then mixed with application errors.

Would it be possible to change it into a 403, set with javax.servlet.http.HttpServletResponse.sendError(int) instead of javax.servlet.http.HttpServletResponse.setStatus(int), to allow error pages defined in web.xml to be used by tomcat.

To work around, currently it is possible to define a custom AuthenticationFailureHandler, but this code has a very low value:

public class KerberosAuthenticationFailureHandler implements
        AuthenticationFailureHandler {

    @Override
    public void onAuthenticationFailure(HttpServletRequest request,
            HttpServletResponse response, AuthenticationException ae)
            throws IOException, ServletException {
        if (ae instanceof BadCredentialsException) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN);
        }

    }

Grant Cermak (Migrated from SES-94) said:

I have a set of changes prepared that add Active Directory support for decoding the PAC to get the groups to which the Active Directory user belongs. This issue will track the submission of this change set.

Brice (Migrated from SES-126) said:

Would it be possible to release the Kerberos Ext and publish it on Maven Central? The latest found on the milestone repository is M2 and is not compliant with Spring Security 3.1.

The code from GitHub is compliant with Spring Security 3.1 but no package is published.

It will prevent users to make their own builds.

Regards