I am trying to wrestle with SSO in weblogic version is 12.2.1.3. We have integrated it with OAM/OID, within a larger application comprising of Oracle Forms & Reports. In addition to Forms, we have various custom servlet-based applications that need to be called from Forms.
This is fine.
Because authentication happens within the Oracle world, through OAM login screen, up to now I didn't have to mess with the Access Management within my Java custom code, apart from getting the username from HTTP headers.
The bad thing is that sometimes we need our servlets to act as middle-man between Forms and Reports. E.g. I need to call various stuff with Reports (on server), transform them and send them back to the client. I know that this doesn't sound right design-wise. But still it's legacy code and we need to make this work - at least need to try..
Previously we used to get away with it passing cookies between requests. But in 11/12g OAM, I am gathering from here that the cookie needed for successful session validation (OAMAuthnCookie) is stripped from the request before reaching my servlet. This seems to happen indeed, basing on the header dumps i am doing, and tracing calls using F12 Developer Tools on the browser.
So.. I have gathered that I need to generate a new OAMAuthnCookie, or something that would create it and attach it to the new http call.. I just would like an expert or somebody who has dealt with this to verify that the following assumption is right - the only way to do this is using OAM SDK (a bit non-intuitive imho).
Another thing - many of the examples that I find about OAM SDK deal with login forms. I don't need to do user authentication, nor do I need to talk with OAM myself to verify if the resource is protected or not. I am dealing with an already authenticated request - need to just somehow get UserSession and user token from HttpServletRequest, in order to generate new OAMAuthnCookie so that my next request (using e.g. apache client) succeeds.. I used to assume that this wouldn't be hard to do, but am a bit stumped now.
Thank you for your attention.
Working with OAM SDK, as far as I cursively saw (at the time of writing this, we were using Weblogic 12c with Access Manager that behaves exactly as described in the documents that talk about OAM 11g - therefore I assume that's the version we are using too), involves
generating ObAccessClient.xml from OAM Console, to establish contact between the code you are working on (which will be called Access Client), and OAM
including JARs from the downloadable OAM SDK with your application
writing code in your application (e.g. in authentication filter, or servlet) to establish communication with OAM via its SDK to finally authenticate/authorize etc.
There is a good guide about how to write the code in Oracle documentation here.
I found also these articles very informative:
Oracle Access Management blog
Oracle A-team Best Practices blog
The code that I had in mind would ultimately generate a new authentication cookie that I would pass to the reports servlet for further authorization (since this cookie is stripped indeed from the request before reaching my application). The only way I found to generate such a cookie would involve changing a setting in OAM console to include another cookie (OAM_IDENTITY_ASSERTION) in the requests, according to another Oracle A-Team article.
In the process of the above investigation, I finally stumbled on this magic reply to a question in Oracle forums. According to it, there is a user setting in OAM console, that allows to switch off the default filtering of OAMAuthnCookie.
filterOAMAuthnCookie=false
In our case, this perfectly suited me. Indeed after the change, the cookie in question was finally reaching my application, with the result of me being able to pass it to subsequent requests to Oracle Reports, without using OAM SDK.
Related
I know that the j2ee spec doesn't allow for directly handing password expiry and change. See IBM redbook "WebSphere Application Server on z/OS and Security Integration" at page 57 where this is clearly stated.
Has anyone managed to create a login suite that uses extensions to detect expired passwords, and allows them to be changed on some other page? I've tried using the com.ibm.390 suite but this seems to fail CICS authorisation when invoked, possibly because the caller is as yet unauthenticated.
This is a java -> ibm cics question so please could you constrain answers and comments to this sphere rather than Spring etc?
java 1.8, cics 5.3, liberty v17
Its the enquiry mechanism and update mechanism that I need assistance with, I can handle the login suite, filters and servlets myself.
You won't be able to use com.ibm.os390.security.PlatformUser in a CICS JVM as it uses __passwd which requires the caller to be program controlled, which is not feasible. If you can call into a CICS program this could issue a CHANGE PASSWORD command. You may also be able to create a Liberty JASPIC provider to assist in the process.
I suggest looking at the CICS API and mapping to JCICS classes. You could write COBOL (or PL/I, or Assembler) programs wrapped around those CICS APIs not exposed by the JCICS classes, then invoke with a channel or commarea.
I'm working on a project which involves writing web services on mainframe enviroment.We are going to be provided a test enviroment on which we can do development and see the inital results. That process is taking a lot of time and I wanted to see if I can simulate some of the parts that I've to do.
Finally I've to get web services talking with mainframes which would have webservice talking with DB2 and IMS segments. I've never worked with mainframes before and I wanted to know how can I create mocks for IMS segment which then my webservice can read and update to. I would appreciate any insights into this
I've done the mainframe side of POX and SOAP web services in CICS. (CICS can access both DB2 and IMS) The thing that seems to surprise the distributed folks is the tag names. They tend to be generated from language structures, so they look like (in our case) COBOL variable names.
Other than that, the SOAP looks like what the WSDL says it should, the POX looks like POX.
If you've got a schema, work from that. Don't worry about the fact that it's a mainframe or that the data is stored in IMS or DB2, write to the specification.
You might want to ask about authentication mechanisms, as this is another stumbling block regardless of platform. Generally people are nervous about unauthenticated access to their business systems, even if that access is coming from another part of the same organization. No one wants to have created an exploitable hole in their security.
In our case, using CICS, we required a logon ID and password for each transaction - http basic authentication as per RFC 2617. Depending on your policies and procedures, that password may be required to expire on a regular basis. Some organizations allow non-expiring IDs, some don't.
An option we looked at but did not implement was SSL certificates. CICS allows one to send a certificate along with a request and then CICS matches the certificate to a logon ID under whose auspices the rest of the transaction runs. The ID is authenticated by virtue of the certificate. This is done in the TCPIPSERVICE definition in CICS.
I realize I'm going on about CICS and you didn't even mention it in your question, but I have to believe you're going to run into similar concepts/issues. IMS also does web services, and I seem to remember there being a mechanism to expose a DB2 stored procedure as a web service. IMS, DB2, and CICS all use the same external security manager behind the scenes.
I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.
I'm looking to roll my own simple user authentication as part of a iOS / GAE app. I'm not wanting to use 3rd party libs such as spring.
I have an iOS client from which I'd like to offer the option to create a profile (hashed UDID, password). Store the login details (keychain?) and auto-login to GAE each time my App starts.
I'm thinking simple HTTP basic-authentication. B64 decode (GAE API for this?), then use the hashed UDID as Key into my various datastore Entities via low level data store API. Then generate some kind of unique session ID (GAE API for this?) to pass around as a URL parameter.
I have fairly good Java/Objective-c experience, but it's my first 'cloud' type app and I have a security concerns about the above approach. Not least because I didn't find any java examples of solving what must be a fairly common problem, which makes me think I'm missing something :)
Some things I'm not sure how to solve;
The URLs could easily be 'network sniffed' or 'binary scanned' from the App opening me up to the possibility of DOS/GAE app abuse.
Is it worth to try and secure the traffic via HTTPS, and is there a way to do this between iOS and GAE (I've never used SSL)
Could I combine this approach with an administration page that would use google authentication.
Does GAE have any built in DOS protection or would I also need to combine that into my authentication approach?
Without GAE threads how do I invalidate a session after a certain amount of time, taskQueue?
I'm new to GAE and excited to get past this first hurdle, so any tips advice is much appreciated!
Some of my experiences though I'm using python you might find some of the observations I make helpful:
You might want to consider OAuth 2.0 as authentication model since it works with most providers.
I first chose a Javascript / OpenID + custom login and now I use serverside OAuth 2.0 + custom login. (I had considered using http://www.janrain.com/ if you're thinkning altenatives to rolling your own.)
A third option for you is to take a custom authentication that is already included with a Java CMS for app engine that already has an authentication system.
You can make a completely custom /admin interface completely separate from the user experience so app engine will be preferable for you since it gives you a lot of control over the code.
If you want to look how a larger Java CMS for GAE does it then you could check in http://www.vosao.org/
I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.
We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.
What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).
I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.
Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.
Or, is there some completely different solution that would work better that we haven't though of?
Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/
Update 2 More information:
The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.
So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.
I think you should be able to do this using a fairly simple custom servlet.
At a high level, you'd:
Map the servlet to a mapping like /foo/*
In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
Pipe the response to the client (some processing may be necessary to handle the headers).
Why not front weblogic with Apache.
This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.
Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.
Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.
If you instead serve out a JSP page you can use the tag to do the request server side.
Then the user will not even know that the resource was external.
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html
a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy Java EE app? What artifact is serving the API (Servlet, EJB, REST service)?
If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.
For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.
Maybe you can provide a bit more information here.