I've configured Spring Authorization server 1.0 which issues JWT tokens using Authorization_Code Grant PKCE. While I test it using Postman (pls see the screenshot), I am presented with the login screen only the first time I click on 'Get New Access Token' and the token is issued successfully. When I click the button again, a new Token is issued without asking user to log in again. However if I click 'Clear Cookies' a login screen is presented.
This is the exact problem I'm facing in my application. When user is issued the Token 1st time, login screen is presented but, after logout, on the subsequent attempts no login screen is presented and the Token is issues straight away. I believe in my logout flow I need to mimic what 'Clear Cookies' does in Postman and this is where I need help. Can someone pls advise how do I achieve this? any example would greatly help.
My application has react js front end and Spring boot rest APIs microservices (catalog, order, Billing etc) on the backend.
Note: Earlier I used CLIENT_SECRET_BASIC for authorization but later changed to PKCE however that doesnt impact the question/issue I am facing.
#Bean
#Order(2)
public SecurityFilterChain appSecurityFilterChain(HttpSecurity http) throws Exception {
http.formLogin()
.loginPage("/login")
.and()
.logout()
.addLogoutHandler(new HeaderWriterLogoutHandler(
new ClearSiteDataHeaderWriter(CACHE, COOKIES, STORAGE, EXECUTION_CONTEXTS)));
return http.build();
}
Related
I need help in implementing Single Logout.I'm able to implement SSO service successfully.But SLO service is not working.
I got RequestDenied status code after performing logout on my OWIN based asp.net MVC application.
<saml2p:LogoutRequest
Destination="https://sap-client.accounts.ondemand.com/saml2/idp/slo/sap-client.accounts.ondemand.com"
ID="idb2d655f7174f465696a433c75a717b46" IssueInstant="2019-08-03T02:16:03Z" Version="2.0"
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml2:Issuer>https://sp.domain.com/Saml2</saml2:Issuer>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">xxx#xxx.com</saml2:NameID>
<saml2p:SessionIndex>S-SP-6aff8686-a642-4381-8ab3-0f18c6815ffe</saml2p:SessionIndex>
<LogoutResponse Destination="https://sp.domain.com/Saml2/Logout" ID="S0e6a2f99-2517-4326-a8ce-2ede2dfe1bfa" InResponseTo="idb2d655f7174f465696a433c75a717b46" IssueInstant="2019-08-03T02:16:04.933Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2001/04/xmlenc#" xmlns:ns3="http://www.w3.org/2000/09/xmldsig#">
<ns2:Issuer>sap-client.accounts.ondemand.com</ns2:Issuer>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
</StatusCode>
<StatusMessage>Identity Provider could not process the logout message received.</StatusMessage>
</Status>
Here is Owin log
Sustainsys.Saml2.Owin.Saml2AuthenticationMiddleware Error: 0 : Error in Saml2 for /Saml2/Logout
Sustainsys.Saml2.Exceptions.UnsuccessfulSamlOperationException: Idp returned status "Requester", indicating that the single logout failed. The local session has been successfully terminated.
at Sustainsys.Saml2.WebSso.LogoutCommand.HandleResponse(UnbindResult unbindResult, StoredRequestState storedRequestState, IOptions options, Uri returnUrl)
at Sustainsys.Saml2.WebSso.LogoutCommand.Run(HttpRequestData request, String returnPath, IOptions options)
at Sustainsys.Saml2.Owin.Saml2AuthenticationHandler.d__4.MoveNext()
ProcessId=14888
DateTime=2019-08-04T06:16:22.3060366Z
Thank you in advance.
The Idp returns an error. You should check the logs on the Idp to get more information on why.
It might also be worth using SAML dev tools for Chrome to check the actual messages, there might be more status codes embedded in the response.
One reason that this might occur is if you have a long lived session in your application that extends beyond the life time of the Idp session. With owin based applications where the external login session is typically swapped to an application login session this might happen - the session life time limit is lost in the swap done in ExternalLoginCallback.
I had an issue regarding the logout . Once i am done with my logout and it's not popping me agin to enter the user name and password , why is it so ?
ttps://github.com/spring-guides/tut-spring-security-and-angular-js/tree/master/oauth2-vanilla
https://github.com/sharmaritesh/spring-angularjs-oauth2-sample
is it not the expected behaviour ? If so please suggest me what to do when i want to do the complete logout that means we have to delete refresh tokens as well i guess. the reason of not asking the username and password in my perspective , It's refresh token is valid and once i click teh login button it directly redirects me to the greeting page with generating the new access token with the help of refresh token.
But i would like to do the complete log out i.e, once the use clicks the logout and user should be able to enter his credentials to get the new refresh token and access token irrespective of the old refresh token expiration.
I really appreciate your help..!!!!
Thanks
Prince
I would suggest posting all of the relevant HTTP traffic flow between client (browser) and server, both the redirects and "back end" traffic.
So, basically take the approach of knowing little about the actual implementation of the client and server, and just focus on the OAuth2 authorization code flow, its a protocol after all. Without this we'll be stabbing in the dark.
In terms of an answer, as a guess the client application may be passing a cookie to the authorization server and your just not seeing it. This is exactly what happened to me with Spring Boot and WSO2 IS 5.1.0
I have a web app which is MVC 5 using OWIN cookie authentication. It also uses AngularJS from which web api calls are made. The Angular code is only invoked after the user has successfully logged in and been authenticated and everything works as you would expect.
However, can someone please explain what component (Chrome, OWIN, IIS, ...) is responsible for eventually issuing a 401 if the user has been idle for 20 or so minutes. In MVC this is not a problem because the redirect automatically re-authenticates but with web api my only option is to get the user to log back in again.
Ok so thats the first thing, who is responsible for timing the session out and giving the 401 (and can i alter it) but ALSO is there any way to get web api calls to keep the session alive so that even if the user is idle the api calls stop it timing out?
Specifically, I have implemented SignalR in a way that the signal to the client results in the client issuing an api call to refresh its data. I realise i could push the refresh but at the moment thats a bit tricky. So whats happening is the updates are occuring nicely but eventually this results in a 401 which i want to avoid.
below is an ideal flow
server logs in => creates cookie sets expiration time, passes it to client
client saves cookies & passes it with each request
server checks the cookies for validity including expiration time
if invalid or expired, server responds with 401
the cookie expiration time can be configured in the CookieAuthenticationOptions. See file ~/App_Start/Startup.Auth.cs
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
ExpireTimeSpan=TimeSpan.FromDays(365),
AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
LoginPath = new PathString("/Account/Login"),
Provider = new CookieAuthenticationProvider
{
// Enables the application to validate the security stamp when the user logs in.
// This is a security feature which is used when you change a password or add an external login to your account.
OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
validateInterval: TimeSpan.FromMinutes(30),
regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
}
});
Set your ExpireTimeSpan to the desired TimeSpan.
For web api calls that fail authentication you could catch 401's and send back a response that tells the browser it's logged out - you could pop up a login dialog or redirect to login url.
I have seen lot of examples where, there is a custom Login page with Angular JS, and then we make a rest POST call with the username/pwd, and then Spring authenticates based on whatever Auth Service we provide. Then we receive a success, grab the user object from Spring Security and then create a Session cookie in Angular.
https://github.com/witoldsz/angular-http-auth/blob/master/src/http-auth-interceptor.js
I also have seen, integrating Siteminder with Spring Security where we install a policy agent on the web server, and then grab request headers with Spring Security, and then pull the roles and build a user profile object.
I'm looking for a solution where I can combine both the above. This is the scenario :
When the user requests for index.html (Angular), the policy agent on the web server intercepts, authenticates with a Siteminder login page and then passes the headers to the app server. The Spring Security on app server will read the headers and pull the roles from our app database and then build a userprofile object. Now here, I want to continue the flow and display angular page, but Im trying to figure out, how do I send the user profile object to angular, because angular is not making a POST call at this point. Also, how do I get the http-auth-interceptor in play, because I need to keep checking if the user is still authenticated on the change of every view/state in Angular.
Help appreciated ! Thanks !
You may implement a tiny JSON REST service "/your-app/profile" which is protected by SiteMinder, reads and evaluates the headers and returns the result as a JSON object.
Your Angular App (e.g. /your-app/index.html) should better also be protected by SiteMinder so you receive an immediate redirect to the SSO Login when accessing it without session. In addition, it must read the JSON REST resource "/your-app/profile" when loaded. It must also expect that SMSESSION is missing when reading "/your-app/profile" and react accordingly - perform a reload of the protected index.html page to trigger a SM SSO re-login (if "/your-app/index.html" is protected, otherwise you must trigger login by a redirect to some protected resource).
If you want to constantly check to see if SiteMinder session is still present, you may either access the "/your-app/profile" or check for the presence of the SMSESSION cookie (only in case it is not set as HTTP-only).
One SECURITY NOTE: If you rely on the seamless SSO which is provided via SMSESSION cookie, be aware of the possible CSRF (Cross-Site Request Forgery) attacks!
Apparently both roles and the username will be available in spring if the integration is done as this describes
Integrating Spring Security with SiteMinder
So I am trying to setup Okta as an identity provider, and I want to login to an application using the Service Provider initiated workflow. I've setup the template SAML 2.0 application in Okta and setup the entry point and SAML certificate on the Service provider. The Service Provider initiates the workflow just fine, a popup opens with the Okta login dialogue. But once the login is complete I am taken into the Okta portal with a list of my apps. What should be happening is a re-direct back to the Service Provider so that it can use the userID to login the user there.
I followed the instruction here for setting up the IdP https://support.okta.com/entries/23364161-Configuring-Okta-Template-SAML-2-0-application
Here is what my config in Okta looks like
Application Label: App Name
Force Authentication: no
Name ID format: EmailAddress
Recipient: https://serviceprovider.com/_saml/validate/okta/
Audience Restriction: https://serviceprovider.com/
authnContextClassRef: Password Protected Transport
Destination: https://serviceprovider.com/_saml/validate/okta/
Response: signed
Assertion: signed
Request: uncompressed
Default Relay State: Leave blank since we are only doing SP initiated workflow
Post Back URL: https://serviceprovider.com/_saml/validate/okta/
Attribute Statements: none
Group Name: leave blank
Group filter: leave blank
I don't see any errors in the Okta portal or in the Okta administration panel, so I can't figure out why it is not completing the workflow and re-directing back to the SP.
Is there a place in Okta to see any errors that might be getting thrown by the process?
Anyone know what might be up?
I had a similar problem a while back. In my case, the "Rquest" was set to "compressed". changing it to "uncompressed" solved the issue. But in your case I see it is already "uncompressed"...
However, try to contact OKTA's support - they can help you out.
The answer is different depending on the type of SAML HTTP BINDING used for the SAML Authentication Request.
For HTTP Redirect Bindings you need to set the Okta Request to "compressed".
For HTTP POST Bindings you need to set the Okta Request to "uncompressed".