Good day
I have an incoming request to my application based on websphere 9 with ltpatoken2 cookie.
Previously, the ltpa key was exported from my websphere and add to another server. The option Application security was enabled.
How I can check, at websphere or at my application, that the token is exists and correct?
And my application should be not avialable for requests without token.
In WebSphere 9, if request contains a LTPA cookie, LTPA cookie will be processed automatically. Inside your application code, if you call API com.ibm.websphere.security.auth.WSSubject.getRunAsSubject(), you will see a subject created form the ltpa token if LTPA token is presented and is also valid.
And you will see unauthenticated subject if ltpa is missing or invalid. Or inside your application, if you call HttpServletRequest.getPrincipal().getName(), you will see a user name represented by the LTPA cookie if it presents and valid, and you will see principal name or see unauthenticated user name if LTPA is missing or invalid.
There's no API to inspect that token, but you can test it implicitly. You can capture browser traffic with Firefox or Chrome developer tools, then after successful login, using either the browser tools or curl, send a modified request without the cookie, or with a bad cookie value, and you should get an authentication challenge since the cookie's not there.
The easiest would be to just add security constraints to your web.xml protecting whole application (you will find many examples), and map security role to All authenticated. Then your application will be available only, if user is already logged in (so the LTPA token exists and is correct), otherwise it will redirect you to login page that you can include in your application and redirect user somewhere, informed that he is not logged in, or whatever you want to do in case there is no valid LTPA token.
Related
I have a Java servlet that accepts HTTP requests, "protected" by KeyCloak. I can manually send a GET request, which redirects me to the KeyCloak login page, and I can log in and see the correct webpage from the servlet. Now I would like to make it such that my other Java application can also authenticate itself and access the webpage.
In my current setup I have the Java servlet running in Wildfly and the keycloak standalone. I have a KeyCloak realm with a user "testuser" with the role "testrole" and client "testclient". To be fair I don't really know what the client does, since it has no role or other attributes set. Should it represent the servlet application or the requesting Java application? What attributes should I set here?
The documentation mentiones JWT Tokens, but I don't know how I can obtain one. The actual request should be to "localhost:8080/testservlet" , do I have to query for a token at the KeyCloak server first, or should I go through the redirect process as when it is "manual"?
I have an existing application and all of a sudden i have been given a task to implement IDP initiated SSO. there is a URL to IDP clicking on it asks me to login with IDP provided credentials, after success login the route moves to our application and than my task start to identify the user and give the proper access. I have the certificate provided from our IDP. How can i achieve this? My application is a Spring MVC Java Application.I am using JBOSS AS 7. I havent done a similar thing before. Can anyone please give a step by step clear picture on this? I saw the Spring SAML extension which i couldnt understand properly to get it integrate with my existing app. Any help in this regard will be highly appreciated.
IdP-Initiated SSO
IdP-Initiated SSO with POST Binding
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
See saml-tech-overview-2.0
So if you are implementing the SP, you have to follow the steps 5 and 6 otherwise 1 - 4.
For the implementation you could use OpenSaml if you do not get it working with the Spring SAML extension.
I need to use WSO2 Identity server with SAML for SSO for my internal application. I came across this beautiful
SAML2.0 SSO with the WSO2 Identity Server article
But i have two questions on this article which i am not sure how works
1) In 5th step it is said "Now the user is being redirected to IDP again. Now the IDP realize this user is already authenticated hence it would issue
a SAML Assertion without prompting any authentication challenge."
How will the IDP realize that user is already authenticated ?
As per my understanding it must be done based on session. Does it mean when authentication request goes from service provider 1 to Identity server (SP1 redirects the request to IS thru browser ), IS will first authenticate the credentials and if successful keep the user object under session.
Now when second authentication request goes to IS thru SP2, same session ID is sent (provided request is sent from another of same browser), IS fins already a user object associated with this session, so trust him. Is this understanding correct?
2)In step 2 it is said that " Now the SP1 can validate the SAML Assertion issued by IDP and let the user log-in. "
what is the specific field/value (under SAML response sent by IP) , SP1 will verify?
3) Where user credentials are stored. Is it on IS side or Service provider side?
Just explain how it works with WSO2IS 5.0.0
When user is authenticated to IDP by providing credentials. WSO2IS creates an authenticated session for user and cookie with is associated with the authenticated session set in to the user's browser. Cookie name would be commonAuthId. you can also find it in your browser once you are authenticated with WSO2IS using SSO. Then user is trying to access another SP using same browser, cookie would be sent in to the WSO2IS and it identifies that there is an authenticated session related to the cookie.
Usually, SP validates the SAML2 Response and Assertion. There are several validations that you can do. But most common would be
Signature of the SAML2 Response and SAML2 Assertion
Validity period SAML2 Response and SAML2 Assertion.
Audience restriction validation in SAML2 Assertion
Destination url and Recipient value
Normally Username would be extracted from the Subject identifier value. Also there may be attributes in the attribute statement, which SP can retrieve and do some validation over them as well.
End users are authenticated to the IDP. So credentials must be in IDP not with the SP. It is one of idea of SSO. Maintains the credentials in one place. WSO2IS is default shipped with LDAP based user store. Therefore end user credentials are stored in the LDAP server. However WSO2IS can be deployed with any existing user stores that you like
I have a web application which requires username and password authentication to enter.
What I am doing is, authenticate a user from a stand alone Java app, which would do so by making Http request to the server using username and password. Then I would retrieve JSESSIONID cookie from response of server.
Now what I want is to use this JSESSIONID to continue session on browser i.e. to let user navigate pages of my web app which would be opened by my stand alone java app which I use for authentication.
Is this possible? Or is there any other way to do so.
Cookie can be changed using below mentioned methods.
Cookie cookie = new Cookie("JSESSIONID", NEWSESSIONID);
response.addCookie(cookie);
From your application you can send JSESSIONID as parameter while opening browser first time and reset your cookie using above method either in filter or servlet. This will reset your cookie in client side once you send response back. Next request on wards you will be able to access the session created previously.
It's possible but it's not that simple.
Since web applications don't share sessions, what you're looking for is a Single Sign On (SSO) solution, which involves an "Identity Provider" (IdM) that authenticates users for one or more "Service Providers" (SP). In this case, your servlet is the IdM and your web app is an SP.
Depending on your deployment, the following are third-party, open-source SSO libraries that you may be able to use:
Kerberos
PicketLink (for JBOSS)
OpenAM (for Tomcat)
If you don't want to use a third-party library, you may also be able to modify your servlet to be the IdM. Either way, I suggest reading a little about Security Assertion Markup Language (SAML) before deciding on a solution. SAML is a popular method that the above libraries implement.
I had a (maybe simple) question about the CAS protocol.
From what I read in the protocol description, using the renew parameter in the /serviceValidate call force the user to provide its crendential again.
2.5.1. parameters
The following HTTP request parameters MAY be specified to /serviceValidate. They are case sensitive and MUST all be handled by /serviceValidate.
[...]
renew [OPTIONAL] - if this parameter is set, ticket validation will only succeed if the service ticket was issued from the presentation of the user's primary credentials. It will fail if the ticket was issued from a single sign-on session.
Since each ticket is specific to a given service, does that mean that the renew parameter force the user to provide its credentials each time he attempt to access the application, even if he already logged in and used other applications ?
Setting "renew=true" on a /serviceValidate URI indicates that a service ticket request will only be validated by CAS if the user obtained that ticket through presenting primary credentials (user id, psw). So, if you are attempting to validate a service ticket when you have already established an SSO sessionin a prior attempt, setting "renew=true" to true will cause the validation to fail.
However, if you are attempting to force the user to enter his credentials every time using the /login URI call to the CAS server, then "renew=true" would be the parameter to use. In other words, if application X is specified as a service URL to the /login URL and renew is set to true, users will be forced to provide credentials regardless of whether or not a previous SSO session exists.
Hope that helps. :)