Keycloak, WSO2 and some other SSO IDP servers offer a possibility of "Single Logout" without forcing browser to redirect to every SP where current user is logged in by sending the <LogoutRequest> over HTTP-POST via back channel.
Unfortunately this does not work if SSO integration in the service is implemented using spring-security-saml2-core library (we are using Keycloack).
All I could figure out from the log file on the SP side was:
[2016-01-13 12:50:56.867] [DEBUG] [org.springframework.security.saml.SAMLLogoutProcessingFilter] - Received logout request is invalid, responding with error
org.springframework.security.saml.SAMLStatusException: No user is logged in
at org.springframework.security.saml.websso.SingleLogoutProfileImpl.processLogoutRequest(SingleLogoutProfileImpl.java:168)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.processLogout(SAMLLogoutProcessingFilter.java:176)
at org.springframework.security.saml.SAMLLogoutProcessingFilter.doFilter(SAMLLogoutProcessingFilter.java:102)
...
The application that uses Spring SAML extension is deployed on the Tomcat 7. It seems that <LogoutRequest> when sent via back-end channel does not have a browser session cookie, and user application session cannot be identified, so user cannot be logged out and the application session of the user will not be invalidated.
However the <LogoutRequest> contains the global SSO session identifier which can uniquely identify the application session. But this does not happen.
Is this behavior of the Spring SAML library intended by desing: do not support back-end communication during Single Logout? or am I missing something and the desired behavior can be configured?
Note: I understand that according to SAML specification HTTP-POST and HTTP-Redirect bindings are intended to be carried via User Agent (web browser), however broad support from SSO IDP servers made me ask this question :)
Thank you in advance!
UPDATE: According to Vladimir Schäfer's comment in the SES-162 ticket it seems to be an intended library behavior.
In Spring-SAML, Single Logout is currently supported with HTTP-Redirect and HTTP-POST bindings. SOAP binding is not available. Refer : Spring SAML Global Logout
Back channel is not supported in spring-saml
No, it is not possible to carry out <LogoutRequest> over HTTP-POST via back channel using Spring-SAML library.
This behavior is against SAML specification and according to Vladimir Schäfer's comment in the SES-162 ticket it will not be supported by Spring-SAML.
SOAP binding is meant for backend channel, but as it is noted by #meetarun it is not implemented in Spring-SAML library at the moment.
Related
Im trying to setup a groovy app where I'm trying to integrate a third party service. They have an OAUTH process where the user clicks on a button and is redirected to their site to login and "grant" my app access to their service (somewhat like facebook). BUT - They are then redirected back to the app with a user "code" in the url as a parameter, which is then used to get an OAUTH token on the user's behalf through a different endpoint. I'm having an issue getting the "code" on the redirect. can anyone help?
wwww.someurl.com?code=2l314jhlk13...2134lkj23h4==
how can groovy listen for the redirect? I don't know where to go from here and the service i am using dosn't have any documentation.
Depending on what service would you like to integrate.
In some of them you can skip redirect. Some of them provides SDK with ready to use solutions.
If nothing - you need to http server.
If you app is a plain groovy without any web frameworks, probably the simplest solution is to use JDK built in http server.
Example - http://glaforge.appspot.com/article/the-jdk-built-in-web-server-with-apache-groovy
If you have an on-device application (e.g. desktop program, mobile device app) you can use OpenID Connect with some caveats:
Using Resource Owner Credentials (grant_type: password) is the simplest, but might not be possible if the authentication server operator won't let you use that grant-type because of trust reasons (i.e. they don't want you collecting the user's username+password yourself) - or if they have a dynamic or custom authentication UI that would be hard to replicate in a native app.
With the interactive flows (implicit, hybrid) the authentication sever's authentication page is shown in an in-app web-view. Most users will have no idea that the application can snoop on the authentication page and capture their username and password, especially on mobile devices - but this way the application code can easily capture the authorization code and/or access token, and automatically dismiss the web-view without any additional user interaction. (I'm surprised I haven't heard of more cases of users' details being captured by malicious apps this way.)
...so the advice is to always open the authentication page using the system's web-browser, but on the Windows desktop there is no good, standard way for the system web-browser to return the server response to the application code, though there are a number of approaches currently in use:
The authentication success page instructs the user to copy and paste a blob of text (containing the authorization code or access_token response) back into the desktop application.
Show the page in an app-hosted web-view, as per the notes above.
If the authentication process always only needs a username and password (for example) the application could still capture the user's username and password with its own UI and then make its own HTTP requests to make it seem like a user's web-browser session, and get the authorization code and/or access_token that way.
On Windows only:
Have a small utility program authHelper.exe that when invoked forwards its command-line arguments to a named-pipe in the user's session.
The main client-application will register authHelper.exe as a temporary URI scheme handler in the per-user HKCU\Software\Classes key, e.g. my-application: such that the contents of any my-application: URI are passed as arguments into authHelper.exe.
The URI passed to the system web-browser to open the authentication page has the redirect_uri parameter set to my-application:, so after the user authenticates in the browser, the browser will request the custom URI scheme which is handled by Windows, which invokes authHelper.exe "access_token=..." which then sends the data down the named-pipe to the running application.
If the user doesn't have permission to write to their own HKCU\Software\Classes key, or if they're using a version of Windows that doesn't support custom URI scheme handlers with EXE registrations then this doesn't work.
Windows UWP applications can also use the Web Authentication Broker.
I was wondering if a different approach could be used: why can't the application simply poll the authentication server for the status of the authentication attempt? Or does this approach already exist, and if so, what is the name of the flow or grant?
Here's the flow I'm proposing:
When the user wants to authenticate, the application opens the system web-browser as before, but with another parameter for a one-time-use opaque ID provided by the application.
As soon as the system browser is open, the application makes requests every 500ms or so (i.e. a polling loop) to the authentication server using its own HTTP client that asks for the status of the active authentication attempt associated with the same opaque ID as before.
The initial few responses from the authentication server to the application will presumably be status: pending, but eventually after the user successfully authenticates within a timeout window then the application's poll request would indicate a successful attempt and also contains the access_token or authorization code as is applicable. If the user failed to authenticate (e.g. 3 incorrect attempts) or left the window open long enough causing a timeout then the poll response would indicate failure.
Does this already exist and does it have a name? Are there any potential security risks or vulnerabilities with this approach?
It exists and has a name, "OAuth 2.0 Device Flow for Browserless and Input Constrained Devices", but is not yet fully standardized, see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow
Google also implemented this flow avant-la-lettre in a vendor-specific way:
https://developers.google.com/identity/protocols/OAuth2ForDevices
I'm currently implementing an OAuth2 authentication using Microsoft Bot Framework and Cortana as one of my channels. However, as I was setting up my OAuth2 configuration with the following details in where I properly set the Redirect URL both from Knowledge Store and apps.dev.microsoft.com
Knowledge Store:
apps.dev.microsoft.com:
Whenever I authenticate to Cortana based from the OAuth2 that I've configured, the redirect URI seems to be always set as https://www.bing.com/agents/oauth. Here's a screenshot of the http request from Cortana Authentication that I got from fiddler:
Which causes this error message:
Any idea how to fix this?
Don't forget that the bot channel (in this case Cortana) needs to be where the redirect points to. Cortana's redirect is https://www.bing.com/agents/oauth.
Documentation here. You can test OAuth via botframework and the emulator. In that case, the redirect is https://token.botframework.com/.auth/web/redirect. Documentation here. If you look at the diagram in the spec on page 10, you'll see that Cortana is the client. The auth call needs to come back to her. You also need to let the auth server know that the redirect URL is allowed. For Microsoft login, you go to the app dev portal, select your app, go add a "web platform" and register the redirect urls. That should solve the problem on both ends.
How should I access the share point web services in iOS which need to be authenticated by TMG. When I invoke login request it returns login HTML template in response as shown below
Can we authenticate TMG firewall somehow in iOS. I am not expecting whole source but any help, references will be appreciated.
Finally we got solution to this stuff. By requesting site info using GetWeb method like
"SOAPAction" : "http:\schemas.microsoft.com\sharepoint\soap\GetWeb"
along with a username, password we received cookies. Then passing these cookies to next share point services we received response and resolved above TMG auth issue.
Questions:
1) What's the best way to integrate OpenID Connect authentication into a webapp that uses Spring Security for authentication?
2) Is there any way - either from the MITREid side of things or the Google Accounts side of things - to get the MITREid OpenID Connect authentication filter to work with Google's OpenID Connect service?
I'm sure answers to these questions will be useful for any developer that uses the Spring Security OpenID module to authenticate with Google.
Detail:
My webapp uses Spring Security's OpenID module (<openid-login .../>) for authentication with Google Accounts as the Identity Provider. ie., users authenticate using their Google Apps or GMail email address.
Recently, whenever users authenticate, they receive this warning message from Google accounts:
Important notice: OpenID2 for Google accounts is going away on April
20, 2015.
So Google is dropping support for OpenID, will turn it off completely in April 2015, and states that you must switch to the OpenID Connect protocol if you want to authenticate with Google Accounts.
I was hoping Spring Security would have built-in support for OpenID Connect, just like it has built-in support for OpenID. e.g. something like an <openid-connect-login .../> element. But my searches have turned up no such support.
The best candidate I've found so far is MITREid Connect . It includes a Spring Security authentication filter named OIDCAuthenticationFilter for OpenID Connect. The problem is, it does not interoperate with Google's OpenID Connect implementation.
I tried cloning the MITREid simple-web-app and configured it to authenticate (using OpenID Connect) with Google Accounts. But it did not work because it depends on a nonce which Google's OpenID Connect implementation does not support. The error message from Google accounts was:
Parameter not allowed for this message type: nonce
Next I tried plugging my own implementation of MITREid's AuthRequestUrlBuilder interface into the MITREid configuration. The only difference between my implementation and MITREid's implementation was that I did not send the nonce.
Not sending the nonce made Google's OpenID Connect implementation happy but MITREid threw an exception when it couldn't find a nonce in the Google authentication response. The error message was:
Authentication Failed: ID token did not contain a nonce claim
I tracked the MITREid exception down to these lines in MITREID'S OIDCAuthenticationFilter:
// compare the nonce to our stored claim
String nonce = idClaims.getStringClaim("nonce");
if (Strings.isNullOrEmpty(nonce)) {
logger.error("ID token did not contain a nonce claim.");
throw new AuthenticationServiceException("ID token did not contain a nonce claim.");
}
But there is no way for me to extend MITREid's implementation to ignore the nonce. So close but yet so far! If Google Accounts would accept the nonce or MITREid could be configured to ignore the nonce then we'd have a solution.
Within the MITREid Connect issues list on github I've found others have run into these similar issues:
1) #726 - Documentation on using client with Google as authentication provider
2) #704 - Add a useNonce attribute into ServerConfiguration to indicate if the IdP accepts the nonce value into its requests.
So I am stuck. Come April 2015 Google will shutdown Open ID authentication.
Some relevant links:
1) https://support.google.com/accounts/answer/6135882
2) https://www.tbray.org/ongoing/When/201x/2014/03/01/OpenID-Connect
3) https://github.com/mitreid-connect
4) https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-client/src/main/java/org/mitre/openid/connect/client/OIDCAuthenticationFilter.java
5) https://github.com/mitreid-connect/simple-web-app
6) https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-client/src/main/java/org/mitre/openid/connect/client/service/impl/PlainAuthRequestUrlBuilder.java
7) https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/726
8) https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/pull/704
2015-02-18 Update
Functionality has recently been added to the development branch of mitreid-connect for disabling the nonce - therefore making Google's OIDC server happy. Thankfully, mitreid-connect has also provided some guidance on interoperating with Google .
Unfortunately the "nonceEnabled" change is not yet available in Maven central but hopefully that will change soon.
AFAIK, there is no clean and easy Spring Security migration from OpenID to OpenID Connect authentication. Implementing OpenID authentication with Spring Security is straight-forward using the well documented <openid-login/> but there exists no analog for OpenID Connect.
The MITREid alternative is still on a development branch and unavailable at Maven Central and therefore not a candidate.
In the comments, Chuck Mah points to How to implement Openid connect and Spring Security where Romain F. provides the sample code.
Romain's sample code pointed me in the right direction. Given time is running out, I went with romain's approach, which was to write a custom Spring Security AuthenticationFilter that uses spring-security-oauth2 to query the oauth2 api userinfo endpoint (for Google that's https://www.googleapis.com/oauth2/v2/userinfo). The assumption is that if we are able to successfully query the userinfo endpoint then the user has successfully authenticated so we can trust the information returned - eg the user's email address.
When i first started learning about OpenID Connect the “id token” seemed to be the central concept. However, browsing the spring-security-oauth2 source code, it appears to be ignored. This leads to the question, what’s the point of the ID token if we can authenticate without it (by simply querying oauth2 userinfo endpoint)?
A minimalist solution - which i would prefer - would simply return a validated ID token. There would be no need to query the userinfo endpoint. But no such solution exists in the form of a Spring Security authentication filter.
My webapp was not a spring-boot app like romain's. spring-boot does alot of configuration behind the scenes. Here are some of the problems/solutions I encountered along the way:
problem: HTTP Status 403 - Expected CSRF token not found. Has your session expired?
solution: java config: httpSecurity.csrf().disable()
problem: HTTP Status 500 - Error creating bean with name 'scopedTarget.googleOAuth2RestTemplate': Scope 'session' is not active for the current thread;
solution: java config: OAuth2RestTemplate does not need to be session scoped (OAuth2ClientContext is already session scoped and that's all that's necessary)
problem: HTTP Status 500 - Error creating bean with name 'scopedTarget.oauth2ClientContext': Scope 'session' is not active for the current thread;
solution: web.xml: add RequestContextListener
explanation: because the oauth2ClientContext session-scoped bean is accessed outside the scope of the Spring MVC DispatcherServlet (it is being accessed from OpenIdConnectAuthenticationFilter, which is part of the Spring Security filter chain).
<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
problem: org.springframework.security.oauth2.client.resource.UserRedirectRequiredException: A redirect is required to get the users approval.
solution: web.xml: Add filter definition immediately PRECEEDING springSecurityFilterChain
<filter>
<filter-name>oauth2ClientContextFilter</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>oauth2ClientContextFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Unfortunately, OpenID Connect does not allow us to request only email scope.
When our users authenticated using OpenID they would see a consent screen like "webapp would like to view your email address" with which they were comfortable. Now we must request scopes openid email resulting in a consent screen asking the user to share their entire public profile with us ... which we really don't need or want ... and users are less comfortable with this consent screen.