I'm working with IBM tools. I have a Websphere ESB (WESB) and a CICS transaction gateway (CTG). The basic set-up is as follows:
A SOAP service needs data from CICS. The SOAP-service is connecting to service bus (WESB) to handle data and protocol transformation and then WESB calls the CTG which in turn calls CICS and the reply is handled vice verse (synchronously). WESB calls the CTG using Resource Adapter and JCA connector (or CICS adapter as it is called in WESB). Now, I have all the pieces in place and working.
My question is about the security, and even though I'm working with WESB, the answer is probably the same as in Websphere Application Server (WAS). The Resource Adaper is secured using JAAS - J2C authentication data. I have configured the security using J2C authentication data entry, so basically I have a reference in the application I'm running and at runtime the application does a lookup for the security attributes from the server. So basically I'm always accessing the CICS adapter with the same security reference.
My problem is that I need to access the resource in more dynamic way
in the future. The security cannot be welded into the application
anymore but instead given as a parameter.
Could some WESB or WAS guru help me out, how this could be done in WESB/WAS exactly?
Can you elaborate a bit further? I don't work with CTG but I believe it is no different from other resources such as JDBC or JMS resource.
On the CTG resource adapter, you have identified credentials that are used for all calls to the CICS.
This is similar to what we do when we work with a Data Source and this approach is agreeable to most people.
I do not see how the J2C credential is welded to the application. The configuration is done # WAS/WESB. The application would simply work with the JNDI resources on the server to which the J2C aliases are configured.
If you elaborate on the dynamic requirement folks can help out.
HTH
Manglu
Related
I have developed a Rest webservice using JERSEY. WIth connects with the oracle database. I have JDBC connection code in my code itself, like the url, IP and username and password. Is is really required to again to configure the database connection on the server? like giving a JNDI name etc. Please help.
Thanks in advance.
Is it really required to again configure
No. It is not required to configure the database on the server, giving it a JNDI name and so forth.
Having said that, JavaEE best practices call for design whereby an application doesn't know the specifics of how to connect to external resources (such as databases). Instead, the application should "look up" that external resource by a logical name, and receives an object through which data can be accessed.
The main benefit in that is that your application code can focus on application functionality, while the application serving environment can take care of low-level aspects such as connection pooling, statement caching and so forth.
The other benefit of following this paradigm is that your application becomes immune to changes in the location of the database: no need to recompile your code, or re-package your application, in order to refer to a different data source. Instead, you could change the data source definition in the application serving environment so it points to a different location, and you're good to go.
we have application(Java based) on which other 8-10 application are dependent.
They are connecting to different Queue/Topics etc to our application.
Many times these queue/topic names get changes and other teams are chasing us for the changes.
So I am working on creating standalone application , which will invoke restful APIs from WebSphere using Java and will provide them details to specific environment(using some simple UI). (I don't want to use database to store queue/topic details which is manual work . Wanted real time Queue/Topic details from IBM WebSphere ,which is hosted in our environment)
I checked IBM WebSphere documentation but didnt get what I am looking for.
Also if there are any APIs for such , how I can authenticate that API (will there be token etc)
Thanks in advance.
WebSphere does not have REST api for this. You need to write your own java application that will connect to Websphere's Deployment Manager (dmgr) via SOAP and query for MQ , and then expose via REST.
See for jython example... https://www.ibm.com/developerworks/community/blogs/a9ba1efe-b731-4317-9724-a181d6155e3a/entry/JMS_queues_monitoring_scripts_provided_by_WebSphere_Level_2_support?lang=en
To list the Queues / Topics that are defined in a WAS server, one way to go is to use JMX and MBeans, ie write a program that will initiate a JMX connection, locate the SIB running in WAS, retrieve the MBeans associated to the Queues/Topics and request detailed information on them
For this, you can also use a tool like JMSToolBox that does exactly that (and much more)
(To be fair, I'm the author of JMSToolBox..)
I work on a project aiming to backport single-sign-on (SSO) to existing Weblogic/T3 based enterprise application. Ideally I would be able to utilize our Windows environment to perform this authentication using JAAS LoginContext and GSSAPI. This is unfortunately not documented for InitialContext provided by Weblogic (or at least I didn't find it yet) and it doesn't seem to have been explored by anyone else.
One idea is to authenticate to a Kerberos-realm (Microsoft Active Directory), pick the service ticket and pass it on through context environment. Custom IdentityAsserter is then required on the server side to extract and verify the service ticket.
Any ideas how to create and configure such IdentityAsserter? How to map the principal authenticated on a perimeter to application principal?
We have considered transforming the application to use http/https instead of t3/t3s but have no plans to follow that path, anticipating laborious tasks of redesign and associated test being somewhat out of the current project scope. As a consequence SPNEGO, servlet-filters, NegotiateIdentityAsserter and associated technologies will not provide us much help.
I've got a j2ee web application using j2ee security, so the identity of the user is propagated from WebSEAL to the application, running in WAS7. I'm now trying to make a SOAP webservices call and propogate the user identity in that webservices call. To do this, I grab the LTPA (WSCredential) and LPTA2 (SingleSignOnToken) using the WSSubject calls and attach them to the webservices call using.
bp.getRequestContext().put(Constants.REQUEST_TRANSPORT_PROPERTIES,sendTransportHeaders);
where bp is my BindingProvider. This all should work. But when I make a webservices call, I get back this exception.
Cause =java.io.IOException: Unable to deserialize the Subjects in this Context
I looked at the fields within the LTPA token and all seems right (same realm between the token and the j2ee security realm webservice I'm calling, the token is forwardable, etc), and I cannot find much about this error online, except for (what seems to be an unrelated) case when trying to pass it into the EJB and one case where the realms don't match.
Any ideas? Thanks.
Can you state clearly as to what you are trying to do here?
You should be able to pass the LTPA tokens across transparently with just configuration instead of trying to write some code to achieve the same.
The Web Applications making the Web Service calls to another WebSphere server.
have a quick read at this.
http://www.ibm.com/developerworks/websphere/techjournal/0607_desprets/0607_desprets.html
Things in WAS7 should be very similar to WAS V6.
HTH
Manglu
#jeffsix: are you trying to make a webservice call from application running in one websphere server to another application in another websphere server? Make sure LTPA keys are same on both server.
I'm trying to understand how the JAAS principal propagates to the Business/EJB tier from web tier.
I've read that the if the roles/realm is configured in login-config & security-context of web.xml then the servlet container will also transparently pass the authenticated principal to the EJB Tier.
Two questions
1.) First & more importantly is that true ? Without any intervention from the developer !
2.) And secondly any idea how that works under the hood.
yes it's true. that's generally the point of ejb, to take the "hard" stuff out of the hands of the developer (e.g. security, transactions, robustness, multithreading, etc.)
it's implementation dependent. i know that in jboss (at least 4.x and before), remote method calls used a custom serialization protocol which had an additional Map of arbitrary information which could be sent along with the request. in this was the auth info as well as other stuff to support clustering. for local method calls i believe they use stuff like ThreadLocals.
There are various "context" pieces of information that get propagated in EJB calls, once you get inside the EJB layer and start doing EJB-EJB calls then Transactions would be an example. Some containers allow you to create your own such context objects too.
Thread-local storage can be used within a process, but generally just assume that the container is in charge and can do the right thing - the actual technique is implementation specific.
Regarding your first question - yes.
Regarding your second question - are you familiar for example with EJB3 interceptors?
The container create proxied objects with "interception code" for the beans,
and in addition the container can track other annotations on the methods and the bean class, for example, to detect the #PostConstruct annotation.
Using the role definition, it can check the configuration (either login-config.xml at older versions of jboss, or standalone.xml in JBoss AS 7 at standalone configuration) and understand what is the definition per each role.
JAAS is used in order to provide you abstraction layer over authentication and authorization.
One of the concepts behind JAAS is login module - it provides you "protocol specific" code that takes care of the actual authorization and authentication.
For example, I'm using in this way Krb5LoginModule to use kerberos.
The Principal propagates to the EJB tier from web tier is configured through the login-config in the web.xml as you had surmised for the most part.
How it is implemented is implementation dependent. The user/group data is also implementation dependent and is configured as part of the application server.
However, one of they ways this is done is through an implementation of the JASPIC provider which is a standard way of obtaining the Principal. Using this allows you to have a different authentication path compared to the standard form login, basic authentication or certificate authentication provided by WEB-INF/web.xml but it is a little bit more work.
JASPIC authentication paths allow more complex scenarios such as header based authentication or two-factor or OpenID. The user database "usually" does not need to be tied to the one in the application server. I say "usually" because WebSphere Application Server ties the authentication to a user configured on the server.