On a tomcat-7 instance I have ApplicationA, ApplicationB and SSO vavle turned on. Both applications are servlet-based and secured with form security method.
When I use web browser, SSO works as intended: when I open ApplicationA for the first time, I'm prompted to enter username and login. After I pass login form I can access ApplicatioB without being asked to login.
Now the usecase is: ApplicationA needs to request some content from ApplicationB. So I open ApplicationA in web browser and enter login and password in a login form. After that ApplicationA creates HttpUrlConntection to ApplicationB to get some content but it only gets ApplicationB's login form instead as it is a new request which is not authenticated.
I expect ApplicationB to be accessed for a programmatic request from ApplicationA without login form because I've logged into SSO in a browser.
Also I need content from ApplicationB as a String in ApplicationA, so I'm not using requestDispatcher.include().
Is it possible?
Thank you.
What I tried is to set all Cookies (there are things like JSESSIONID and JSESSIONIDSSO) and headers from my browser request to HttpUrlConnection via conn.setRequestProperty() but no luck.
In order to enforce Single-Sign-On, the applications must be accessed from same client and not from different clients.
So, it is not possible because you are accessing ApplicationB via HttpUrlConnection within ApplicationA, which is now acting as a new client similar to web-browser client, although both applications are enabled SSO by Tomcat.
Also, setting cookies and headers of web-browser client session in HttpUrlConnection client session will not be honored by Tomcat because HTTP connections are coming from different clients.
Related
I have created a REST application in Delphi using kbmMW middleware. It works really great, is fast, efficient etc. But in testing I've used both a Delphi client - which more closely simulates how it will be used in production (iOS, Android, Windows Tablet clients), and several different web browsers with manual REST uri entry.
The REST response format for the most part is JSON, but can be anything I want it to be. One of the REST calls I coded returns the session token.
In order to obtain the session token one has to request a resource using https; when the server sees that you have not yet authenticated it kicks back a 401 unauthorized, which tells the browser to force an authentication dialog, seeking username and password, or triggers the indy client to supply the pre-coded credentials.
I set the internal, kbmMW-wrapped Indy http component to use basic authentication (only inside ssl, of course); once authenticated the server generates a session-based token and returns the token to the client.
When I test this in my Delphi client, which uses Indy's TIdHTTP client, and I set it to use basic auth, set the username and the password, and initiate the request, the Indy components preserve the session token and apparently reuse it. I can call the function on the server that returns my session token, and the token remains the same for the lifetime of the session.
If I authenticate with the browser and the un/pw dialog, then call the function to return the session token, I am required to authenticate once using un/pw, but every subsequent request to retrieve the session token returns a different token every time.
My question is, does this mean that a web browser poses a potential security risk to my server? What governs how long a session lasts when the requesting client is a TIdHTTP vs. when the requesting client is a web browser (I've tested IE, Chrome, Firefox, Opera - all the same response)?
Why does a browser get a different token with every request, while an indy client reuses the same token over and over until expiration?
Does this mean that a potential hacker could compromise my server by utilizing a DDOS attack vector and creating sessions on my server until it runs out of memory?
I thought that the Indy http server would distinguish a requestor based on form vars like Referer, IP Address, Browser type etc. How can a browser, executing the same request over and over with the same IP, Referer etc. force a new login at the server side each time?
Is the browser caching the username and password and ignoring the token?
The server side authentication event only fires once with an indy client request, but fires with every request from a web browser, resubmitting the un/pw combo every time, and ignoring the token.
Should I set an ETag in the response header to the token so that the browser won't keep logging in and creating new sessions?
Help!
I'm trying to integrate Okta as a third party Identity Provider for a system I am working on that is using the IdentityServer 3 framework to support my customers that use Okta. I have everything working great except log out. When a user logs out of my system, it initiates the end session call back to Okta to log the user out. My problem is that the Identity Server is sending a session id along with the post logout redirect uri for context, but Okta refuses to accept the redirect uri because it is not known. I've tried multiple variations in the setup in Okta for this url but because the id value is dynamic, i'm not able to specify an exact url. Is there a way to have it support any urls that are going to a specific hostname or even up to the page path? I've tried adding my host into the API security area for trusted origins but it did not work either. I've also tried overriding the postback url for my system to be a static page, but then the IdentityServer Signout message cookie is never cleaned up correctly. This same code works without any problems when running for Azure as the IDP. Has anyone run into this before and have any thoughts? Any help is appreciated.
An example of the post to Okta at signout with the postback url is something like this,
https://dev-xx.oktapreview.com/oauth2/default/v1/logout?post_logout_redirect_uri=https%3a%2f%2fmyurl.com%2fidp%2flogout%2f%3fid%3d83617adbc6769e5d4d0fbca4dced3991&max_age=5&id_token_hint=eyJraWQiOiJ1aXJYc1RYTkTVVGenBXU1JfMWt6WndNSXBQQUVqT0dndWhjbloxR3pNIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHU4eTlrajNyT2NreW11cTBoNyIsIm5hbWUiOiJKYW1lcyBSZWFtZXMiLCJsb2NhbGUiOiJlbi1VUyIsImVtYWlsIjoiamFtZXMucmVhbWVzQHJlYWxwYWdlLmNvbSIsInZlciI6MSwiaXNzIjoiaHR0cHM6Ly9kZXYtNDg5MDgyLm9rdGFwcmV2aWV3LmNvbS9vYXV0aDIvZGVmYXVsdCIsImF1ZCI6IjBvYWVvdXMycWFJTWJ3U0dhMGg3IiwiaWF0IjoxNTM2MjQ5NzY2LCJleHAiOjE1MzYyNTMzNjYsImp0aSI6IklELlVUem5sTC1FRUY0aHFoZlNSbG5wV1cyUGRxQzlBRk1PcDZiOTh6UERRUUEiLCJhbXIiOlsicHdkIl0sImlkcCI6IjAwbzh5OWZycXVmOFlpaG50MGg3Iiwibm9uY2UiOiI2MzY3MTg0NjU0NTA1NzI4ODQuWldOaVlqZG1aamt0Wm1Fd01TMDBNVGc1TFRreE4yTXRaR1kzTWpreVl6ZGpOekprTm1GbU16WTJaRFl0TURBeE15MDBNMkUwTFdJM01ERXRNek5oWTJOaU1qZ3daamd4IiwicHJlZmVycmVkX3VzZXJuYW1lIjoiamFtZXMucmVhbWVzQHJlYWxwYWdlLmNvbSIsImdpdmVuX25hbWUiOiJKYW1lcyIsImZhbWlseV9uYW1lIjoiUmVhbWVzIiwiem9uZWluZm8iOiJBbWVyaWNhL0xvc19BbmdlbGVzIiwidXBkYXRlZF9hdCI6MTUyMzYyNjUzMiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImF1dGhfdGltZSI6MTUzNjI0OTc2NiwiY19oYXNoIjoiMWoxa1JTSGhObGRGWGNmSDdCQXRBUSJ9.gvG_8dnlAMr9XI-atCjIKVF04L4oMzerXmeT0BAG76RLle-q2pgb8PDvV4cTicLH16QLzboSgocC6t6WoegbUeJLLuzZHd2rQkm8Y4iRheoV05uKhd2mpLA9LyexlJ9oVJ8Xi_D4BqN_bygphAv79B4L8-Ezz3YgGDmSkK3WutB55_r_7XM0OCCCetvNu4S8KXbKHUxgg5cpQ6y7o-d5eIH6I8bpoOoA0gy7Liwsm7IyQUe5_jdorObgBHIEfDx4mjNRENJUQ7InASwbL7eND7COZYyXRwzn7vHU0_XkBaUW9wsY-VJUaihOwEcgVS1MPbGLoSUY9k0TmcUVN3-Q&state=83617adbc6769e5d4d0fbca4dced3991&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554
the id=83617... is what is tripping up Okta from trusting the redirect url. I've tried adding all of these combinations of urls into the logout redirect uri setup and none let it accept it,
https://myurl.com/idp/logout/
https://myurl.com/idp/logout/?id=
https://myurl.com/idp/logout?id=
https://myurl.com
https://myurl.com/
https://myurl.com/idp
https://myurl.com/idp/
https://myurl.com/idp/logout
None seem to work.
I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).
I turned on security authentication in my orbeon app and now I log in remotely to the app via rest api (I send post request on url https://localhost:8444/orbeon/j_security_check).
Now I want to logout from my app but I don't know where to send the request.
I would check what happen (what http request is issued) after I click logout button but there is no logout button in orbeon.
All I found in documentation is this:
<p:processor name="oxf:session-invalidator"/>
but I have no idea how to use it.
Please help
Since you mention j_security_check, I imagine that you've setup FORM-based authentication in Orbeon Forms' web.xml. Note that you're here in pure "servlet territory"; there isn't much of this that is specific to the Orbeon Forms web app in particular. Since you're using FORM-based authentication, the server knows who you are after you logged in because the browser sends the JSESSIONID cookie Tomcat set when you logged in. To logout, you want to tell Tomcat "invalidate that session". To do so:
The simplest way is most likely to write a JSP that calls session.invalidate().
If you're already doing things with XPL within Orbeon Forms, you can write an XPL file that calls the <p:processor name="oxf:session-invalidator"/> and hook that XPL to a URL through the page flow.
How can I implement a cookie based single sign on without a sso server?
I would to share the user logged in across multiple applications using
only a cookie on the browser.
In my mind it's working like this:
user logs in an application
the application verifies the credentials and then it setting up a cookie on
the browser storing the username (that could be coded with a private key)
if the user opens another application, it searches the cookie and reads
the username on the value (using the key for decode the string)
In this solution a user may see the browser cookie (of a another user)
and take the string codified of the username. Then he could adding it on
an own cookie (no good!).
There's some secure way to do this? With a timestamp based control or
something like this?
Thanks in advance.
Bye
P.S.
I know that my english isn't very well.. sorry for this!
This is impossible. Cookies are unique to each domain, and one domain cannot read another domain's cookies.
I think the answer comes a little late, but maybe I can help someone.
You can have a cookie / localStorage in an intermediate domain connected to the home page using an iframe
1) Login
The login form in any of your domains deposits the identification token in a cookie on sso.domain.com by an event (postMessage)
2) Verification
domain1 and domain2 include a iframe pointing to sso.domain.com, which reads the token and notifies the home page
To simplify development, we have released recently a cross domain SSO with JWT at https://github.com/Aralink/ssojwt
There is a simple solution without using an sso server, but not with 1 common cookie, as we know that cookie's are not shared between domains.
When the user authenticates on site-a.com, you set a cookie on site-a.com domain. Then on site-b.com, you link a dynamic javascript from site-a.com, generated by server side script (php, etc) who has access to the created cookie, and then copy the same cookie on site-b.com on the client-side using js. Now both sites have the same cookie, without the need of asking the user to re-login.
You may encrypt/encode the cookie value using a method that both site-a and site-b knows how to decode, so that site-b will be able to validate his cookie copy. Use a common shared secret that without it will be impossible to encode or decode.
You see that on the 1st page load of site-b.com, the cookie is not present, therefore if you see necessary, you may want to do a page reload after setting the cookie.
I have done something similar. There is a PHP application where the user logs in, the system contact a web service and then the service checks the user's credentials on the Active Directory. When the user is authenticated, his PHP session is stored in the DB. Another web application can read the PHP session from the cookies and uery a web service in the PHP applicaiton, the PHP application check the session in the database and return the user id. In this way I have a SSO using SOA.
Do not rely on the user id stored in the browser, is a security error, at least encrypt the id.
The best solution would be to put the login form and session storage in the same application, then this application can provide services to other applications.
And use HTTPS for the kind of infomation exchange.
The cookies can be read only if the belongs to the same domain, for instance:
intranet.example.com
crm.example.com
example.com/erp
You can access cookies across subdomains, but I do not think using browser cookies is a great solution. You really don't need a "SSO server" to implement a single sign-on. It is fairly easy to come up with a payload that both applications recognize. I have seen custom SSO solutions that transmit the payload using XML over HTTPS.
Here is a solution (which will hopefully get heavily scrutinized by security gurus on here):
Have each domain store user data in a similar cookie, and when a user want to jump from one domain to another without authenticating themselves on the new domain, provide a "jumplink" with an encrypted token in the query string. The new domain would decrypt the cookie, and figure out who the user is, then issue them a new cookie for that domain. You would want the "jumplink" to have a very short expiration date, so I would not generate them right into the page, but generate links to a "jumplink" generator and re-director.
This might not be necessary, but the receiving page for the "jumplink" could make a web service call back to the originating domain, to verify the authenticity of the encrypted token and the whether it's expired.
I think this solution would be susceptible to man-in-the-middle attacks (not sure if it would be more so than other auth mechanisms which are currently popular), but you could incorporate a client MAC address and IP address into the encrypted token for extra security.