Security Context Propagation between Managed Servers

          I'm using WLS 8.1 SP2. I have one domain, two managed servers, each on a separate
          hardware server. Each managed server hosts a different web application. I want
          to authenticate to Web App "A" and be able to invoke Web App "B" (from "A") without
          having to re-authenticate. Is this possible via configuration and, if so, how?
          Thanks.
          

Frank,
You do not have to do anything to propagate identity between the two
containers. As long as the user is authenticating first..
There have been a number of issues with the propagation, so be sure to stay up
on the service packs.
HTH.
Frank wrote:
How do you propagate security context information from Servlet to
EJBs? I have an web app that uses the container's FORM based authentication.
The servlet resource then calls a session EJB (w/ security contraints
setup). The webapp and the ejbs are bundled into one EAR.
Thanks!--
Tom Mitchell
[email protected]
Very Current Stoneham, MA Weather
http://www.tom.org

Similar Messages

  • Propagating Security Context between Managed Servers

    I'm using WLS 8.1 SP2. I have one domain, two managed servers, each on a separate
    hardware server. Each managed server hosts a different web application. I want
    to authenticate to Web App "A" and be able to invoke Web App "B" (from "A") without
    having to re-authenticate. Is this possible via configuration and, if so, how?
    Thanks.

    "K Northey" <[email protected]> wrote in message
    news:[email protected]...
    >
    I'm using WLS 8.1 SP2. I have one domain, two managed servers, each on aseparate
    hardware server. Each managed server hosts a different web application.I want
    to authenticate to Web App "A" and be able to invoke Web App "B" (from"A") without
    having to re-authenticate. Is this possible via configuration and, if so,how?
    >
    Does the following do what you want?
    http://e-docs.bea.com/wls/docs81/security/thin_client.html#1039551
    Multiple Web Applications, Cookies, and Authentication
    By default, WebLogic Server assigns the same cookie name (JSESSIONID) to all
    Web applications. When you use any type of authentication, all Web
    applications that use the same cookie name use a single sign-on for
    authentication. Once a user is authenticated, that authentication is valid
    for requests to any Web Application that uses the same cookie name. The user
    is not prompted again for authentication.
    If you want to require separate authentication for a Web application, you
    can specify a unique cookie name or cookie path for the Web application.
    Specify the cookie name using the CookieName parameter and the cookie path
    with the CookiePath parameter, defined in the WebLogic-specific deployment
    descriptor weblogic.xml <session-descriptor> element. For more information,
    see session-descriptor in Assembling and Configuring Web Applications.
    If you want to retain the cookie name and still require independent
    authentication for each Web application, you can set the cookie path
    parameter (CookiePath) differently for each Web application.
    As of Service Pack 1, BEA Systems added a new capability to WebLogic Server
    that allows a user to securely access HTTPS resources in a session that was
    initiated using HTTP, without loss of session data. To enable this new
    feature, add AuthCookieEnabled="true" to the WebServer element in
    config.xml:
    <WebServer Name="myserver" AuthCookieEnabled="true"/> Setting
    AuthCookieEnabled to true causes the WebLogic Server instance to send a new
    secure cookie to the browser when authenticating via an HTTPS connection.
    Once the secure cookie is set, the session is allowed to access other
    security-constrained HTTPS resources only if the cookie is sent from the
    browser.

  • SAML2 between Managed Servers in same Weblogic

    Hi,
    I need to configure SAML V2 between 2 or more applications deployed in WebLogic 10.3.6 server.
    My problem occurs when I try to use application in same weblogic, different managed server.
    * App1 call App2 within an iframe.
    * When I access App1, logon page works.
    * When I access App2 within iframe, credentials was transfered perfectly from App1 to App2.
    * When I return to App1, session is ended.
    Deploying apps on diferent weblogic all works fine and I can access App1 and App2 normally.
    Deploying apps on same weblogic, same managed server, credentials are sharing automatically even SAML not configured.
    I can't understand why App1's session was killed when I access App2 in same weblogic and different managed servers.
    Does someone can help me?
    Regards

    I am setting a different cookie for each application. First app show login form and authenticate correctly but when I open second app, credentials was not recnognized.

  • Security info propagation across weblogic servers

    Hi,
    I have a requirement wherein my biz layer needs info abt logged in user profile. the web layer authenticates user using weblogic internal ldap and calls session bean of biz layer. In the biz layer i m able to retrieve the loggedin userid using sessionContext.getCallerPrincipal(). But i do need more info like user_preferences,emp_id as well. Is there a way of setting these attributes in Context obj which gets propagated across weblogic servers transparently. Otherwise i need to modify all my session bean api to accept userPreferencesDTO as additional parameter.
    Please advise,
    venkat

    have you find any solution for this...

  • Communicating between Managed Servers

    Hi,
    I have multiple Managed servers running on the same host, each hosting one web
    app on a particular port.
    The Admin server runs on port 7001.
    Example :
    The Managed Server hosting the Session Manager is running on 7100, and the
    Managed server hosting the DSLTools is running on port 7200.
    The following link works -
    http://localhost:7100/sessionmgr/servlet/sessionmgr
    Now when I click on DSLTools button on the page displayed by the above link,
    it takes me to
    http://localhost:7100/dsltools/servlet/dsltools
    whereas, I want it to take me to
    http://localhost:7200/dsltools/servlet/dsltools
    If I type the http://localhost:7200/dsltools/servlet/dsltools
    in the web browser, it works.
    So, ques is how can I go from Session Manager running on port 7100 to
    DSL Tools running on port 7200 ?
    I am trying Proxy by path using ProxyServlet, but it doesn't seem to work.
    I don't want to hard code the port numbers in the Session Manager servlet
    for obvious reasons.
    A quick response will be appreciated.
    Thank you very much
    -Anil Varma

    Hi Chris,
    Thanks for your suggestion. I am going to try you suggestion
    and hope somebody responds to it.
    Thanks
    -Anil
    "Chris Chiodo" <[email protected]> wrote:
    Hi Anil,
    You might consider asking this same question on the
    "weblogic.developer.interest.servlet" newsgroup. The people monitoring
    that
    group would be likely to know the answer to this question.
    Thanks
    Chris Chiodo
    BEA Systems
    "Anil Varma" <[email protected]> wrote in message
    news:3f1c020e$[email protected]..
    Hi,
    I have multiple Managed servers running on the same host, each hostingone
    web
    app on a particular port.
    The Admin server runs on port 7001.
    Example :
    The Managed Server hosting the Session Manager is running on 7100,and the
    Managed server hosting the DSLTools is running on port 7200.
    The following link works -
    http://localhost:7100/sessionmgr/servlet/sessionmgr
    Now when I click on DSLTools button on the page displayed by the abovelink,
    it takes me to
    http://localhost:7100/dsltools/servlet/dsltools
    whereas, I want it to take me to
    http://localhost:7200/dsltools/servlet/dsltools
    If I type the http://localhost:7200/dsltools/servlet/dsltools
    in the web browser, it works.
    So, ques is how can I go from Session Manager running on port 7100to
    DSL Tools running on port 7200 ?
    I am trying Proxy by path using ProxyServlet, but it doesn't seem towork.
    I don't want to hard code the port numbers in the Session Manager servlet
    for obvious reasons.
    A quick response will be appreciated.
    Thank you very much
    -Anil Varma

  • SCOM 2012 client movement between Management servers

    Hi all,
    I know In SCOM 2012 sp1 all management servers are peers , if I have five management servers ( A, B, C, D,E ) and 2 gateway servers ( F, G ) . One client is assigned to A management server , in case if that management server down , to which management servers
    or Gateway server that particular client will move any rule.
    Thanks,
    Sengottuvel M

    By default, "the first available management server". There is a black-box algorithm that works behind the scenes in terms of agent failover selection. The only way to control this is to set agent failover lists, and this is only possible via the command
    shell (powershell) - but it's relatively easy to do.
    Here are a couple interesting articles about the topic:
    http://blog.scomskills.com/agent-managementlist-primary-and-failover-configuration/
    http://blogs.technet.com/b/jonathanalmquist/archive/2009/11/11/set-failover-management-server-for-gateway-role.aspx
    ...and there are probably 100 other blog posts talking about the same thing.
    Jonathan Almquist | SCOMskills, LLC (http://scomskills.com)

  • Ejb 3 security - enhanced security context propagation

    after working on several spring based web applications I am working on my 1st EJB 3.0 app.
    The main user groups are "customers" that perform actions on their own behalf and "agents" who perform acts on behalf of customers.
    I don't want to pollute my service layer method signatures with a "user" parameter for every method that needs to know the user it is executing an action on behalf of.
    I believe the various methods on the EJBContext related to authentication/authorization such as getCallerPrincipal(), isCallerInRole() etc are used to resolve these issues. For instance, the impl of a method named getActiveOrders() could use the name of the Principal to look up the customers active orders.
    However, when an "agent" executes methods (e.g. getActiveOrders()) they are typically acting on behalf of a user. So when an agent executes getActiveOrders(), they want to see the orders for the user they are serving.
    Using a custom HTTP based stack for service method invocation, I could propagate this information by adding the "acting on behalf of user XX" information as HTTP headers on the client side and reading them on the server side using an HTTP filter.
    However, I have no idea how to accomplish this inside the confines of an EJB application (JSP front end - presentation and service layer may or may not be collocated in the same VM)? I would strongly prefer a standards based solution.
    Carlos

    Hi,
    You could provide two services: one which is tailored to the agent's use case and one for the general user. The two services would differ in their security configuration but would share a common implementation so that you aren't duplicating any code.
    Here is a sample interface called AccountManager.java and bean called AccountManagerBean.java.
    package acct;
    import java.util.List;
    import javax.ejb.Remote;
    @Remote
    public interface AccountManager {
        // get active order for current account
        public List getActiveOrders();
        // get active order for another account
        public List getActiveOrders(Integer _customerID)
         throws CustomerAccessException;
    }The implementation uses a common private method for the order lookup (doGetActiveOrders).
    package acct;
    import java.util.List;
    import javax.ejb.Stateless;
    import javax.ejb.SessionContext;
    import javax.annotation.security.RolesAllowed;
    import javax.annotation.Resource;
    @Stateless
    public class AccountManagerBean implements AccountManager {
        @Resource private SessionContext ctx;
        @RolesAllowed("customer")
        public List getActiveOrders() {
         // lookup account id for this customer
         // something like "lookup(ctx.getUserPrincipal().getName())"
         Integer customerID = new Integer(-1);
         return doGetActiveOrders(customerID);
        @RolesAllowed("agent")
        public List getActiveOrders(Integer _customerID)
         throws CustomerAccessException {
         // special code to see which agents can modify which account
         // if agent isn't approved, throw an exception
         return doGetActiveOrders(_customerID);
        private List doGetActiveOrders(Integer _customerID) {
         return null;  // to be coded
    }

  • Transaction span two WLS managed servers (non-clustering)

    (Weblogic 6.1 - non-clustering version)
    I have two managed servers configured on a single machine on different
    ports, and I am not using clustering weblogic. Assuming I have EJB A
    deployed on managed server 1, and EJB B deployed on managed server 2.
    I want to have EJB A to invoke EJB B. In EJB A, I guess I will
    probably create the InitialContext with the URL of managed server 2,
    then do the JNDI look up and call EJB B.
    My questions are:
    - Can weblogic handle transaction that spans two managed servers
    (non-clustering setting)?
    - Does weblogic use XA to handle transaction between managed servers?
    - Do I need to do any JTA code in order to achieve that (instead of
    just letting the EJB container to handle the transaction for me)?
    Thanks in advance!
    B.L.

    Hi,
    "benson" <[email protected]> wrote in message
    news:[email protected]..
    (Weblogic 6.1 - non-clustering version)
    I have two managed servers configured on a single machine on different
    ports, and I am not using clustering weblogic. Assuming I have EJB A
    deployed on managed server 1, and EJB B deployed on managed server 2.
    I want to have EJB A to invoke EJB B. In EJB A, I guess I will
    probably create the InitialContext with the URL of managed server 2,
    then do the JNDI look up and call EJB B.
    My questions are:
    - Can weblogic handle transaction that spans two managed servers
    (non-clustering setting)?Yes, it can.
    - Does weblogic use XA to handle transaction between managed servers?Yes, it does. Make sure you use TX DataSources. If the servers are connected
    to different databases, TX DataSources should be based on connection pools
    used XA drivers.
    - Do I need to do any JTA code in order to achieve that (instead of
    just letting the EJB container to handle the transaction for me)?No, you don't. WebLogic will take care about handling
    distributed TXs.
    Regards,
    Slava Imeshev

  • JNDI, EARs and managed servers

    I have an EAR file containing a WAR and two EJB JAR files. When I deploy this EAR
    onto a server (admin server), assign a target to the 3 modules and run, evertying
    is fine.
    I now have a scenario where I have added a managed server (so there are two targets
    to pick from). I deploy to the admin server as before but I change the target
    for the Web module to the new server. This is a typical deployment scenario where
    the web container runs on a different server (perhaps in a DMZ) to the EJB container.
    Now when I try and run the web app, the servlet fails with a naming exception
    - it can't find the EJB in the JNDI tree. Sure enough when I go to the console
    and look, the EJBs are only in the JNDI tree on the first server (those they are
    targeted to). So the servlet is quite right to complain.
    Is then JNDI tree not shared between managed servers? Shouldn't the EJBs be seen
    even though they are on separate servers?
    If I make the new server a target on the EJBs then it is obviously resolved but
    I don't want these remote EJBs on my Web Application server. These are not, and
    shouldn't be, clustered servers.
    How do I get around this? Do I have to specify the URL_PREFIX of the first server
    in my InitialContext properties? This is not very good if I want to move my EJBs
    to a different target, I would then have to change the URL_PREFIX again.
    I'm using WLS 6.1 sp1

    I think renaming them in the config.xml IS the easy way. You cannot do it through the console. Truthfully, that is a planning step and you should probably have the correct names before building in order to avoid other issues. Might be easier to just recreate the managed servers.

  • How to pass the security context between different OC4J servers

    My problem is the following: it seems that there is no standard J2EE solution in a production environment with more than one J2EE application server products to pass the security context between different J2EE application servers.
    I have a distributed application on two different OC4J servers, let's say that we have the web layer (with servlets) deployed on a server instance Server1 and the EJBs deployed on a second OC4J server Server2. If an user is authenticated at the web tier (in Server1) it gets a Principal object. It seems that the same Principal object cannot be used for authorization in the second application server, Server2. This means that in the server Server2 the authentication should be done again. It means that it should be duplicated the mechanism for authentication on Server2 (together with the passwords, users, and so on), thing that is a clear disadvantage of this approach.
    Do you know if there is a specific OC4J solution for this approach?
    Thank you,
    Marinel

    I have a simmilar issue? Did you succeeded to find a solution?

  • How to share security context between different application ?

    Hi all,
    I have two applications(ADF faces + BC, JDev 10.1.3.1) deployed into OAS 10.1.3.1.
    The two applications are :
    1) SalesApp -> main menu page = SalesMenu.jspx
    2) ReportApp -> main menu page = ReportMenu.jspx
    I want implement security using CustomLogin.
    The question is :
    How can I share security context between the applications ?
    What I mean is, from SalesMenu.jspx there is one menu item to jump into ReportMenu.jspx, and I want user no need to Login again, Login is once and the user is recognized in the two apps. How to achieve that ?
    Thank you for your help,
    xtanto

    Xtanto,
    actually you can't if these are separate J2EE application deployments. The session is not shared and thus the authentication is lost. I heard that OracleAs is planning to implement a feature that allows you to share the session and thus a context between two J2EE deployments. I am not 100 % sure this is the case and will check with OC4J Product Management
    Frank

  • SSO with AD error:An error has occurred propagating the security context...

    Hi.
    On Windows 2003, I have installed BOXI Edge 3.1 with SAP Integration Kit. My primary and only use of the SAPIK will be for retrieving SAP data for BOXI reports. I DO NOT want to use SAP Authentication. For BOXI, I want to set up only AD Authentication, but because the web.xml files change with the installation of the SAPIK, I have not been successful at setting up AD Authentication. I have modified the web.xml files so that they look like the original web.xml files (without SAPIK).
    The AD groups are imported successfully into BOXI. The members of those groups are imported successfully, too. But when a user attempts to login, they get error: An error has occurred propagating the security context between the security server and the client.
    I have tried nearly everything to clear this error and there are no Kerberos errors in Wireshark logs on the BOXI server.
    Help!
    Thank you!
    Luis
    PS - I asked this question in the SAP Integration Kit forum, and they suggested I ask here, I guess because in the end it may have nothing to do with the SAPIK...

    Thanks, Tim, for your willingness to help.
    The problem is resolved.
    I noticed in the Local Security Policy that the right "Log on as a service" displayed only the service account user ID, without the domain identifier - where I expected it to show as "DOMAIN\svcaccount", it only showed "svaccount".
    I stopped the Tomcat and SIA services, I removed "svaccount" from the list in "Log on as a service", I reset the account information in the Tomcat and SIA services as "DOMAIN\svcaccount" and saw that change reflected in "Log on as a service" and now AD Authentication works beautifully.
    My guess is that it must have been using the local account and not the domain account for running the services.
    Next task: SSO...
    Wish me luck!
    Thanks!
    Luis

  • Linking JMS Queues between two managed servers

    I have an environment setup with an AdminServer and multiple managed servers all under the same domain and on the same cluster. They are all running under the same Instance of weblogic on one Windows Server.
              I have two different applications on two managed servers that need to have a JMS Queue be linked between them. Essentially have Server1's 'inbox' link to Server2's 'outbox' and Server2's 'inbox' link to Server2's 'outbox'. Each has their own name for their inbox or outbox.
              Server1(inbox)=Server2(outbox)
              Server2(inbox)=Server1(outbox)
              I've tried using Foreign JNDI Providers, however it doesn't allow me to input two addresses (Server1 and Server2).
              Is there another function that would do the same thing?
              Thanks!

    You can make use of Message Bridges between any 3th party JMS provider or SAF (store & forward) if both jms servers are weblogic servers.
              Schelstraete Bart
              [email protected]
              http://www.schelstraete.org
              http://www.linkedin.com/in/bschelst
              Edited by bschelst at 04/07/2008 1:27 PM

  • Transaction Context Propagation

    Can transaction context be propagated from one WebLogic Server to another? If yes, what is then the relationship between the two Transaction Managers in each server?
              

    Zhenxin,
              Transaction can be propagated between multiple instances of the server.
              In releases 5.1 and below, all databse access in this case was delegated to 1 jdbc connection in 1 pool on 1 server, and the database transaction manager was used.
              In 6.0 and above, the transaction is co-ordinated by the TM in one instance of the server, which calls on the remote instances during the pre-commit and commit phases.
              I believe that currently the 1st server to be invoked in the transaction is the one who gets the commit responsibility, but this is an implementation detail that may
              change in future.
              I hope that helps.
              Regards,
              Peter.
              Got a Question? Ask BEA at http://askbea.bea.com
              The views expressed in this posting are solely those of the author, and BEA
              Systems, Inc. does not endorse any of these views.
              BEA Systems, Inc. is not responsible for the accuracy or completeness of the
              information provided
              and assumes no duty to correct, expand upon, delete or update any of the
              information contained in this posting.
              Zhenxin Wang wrote:
              > Can transaction context be propagated from one WebLogic Server to another? If yes, what is then the relationship between the two Transaction Managers in each server?
              

  • Current Security Context Not Trusted When Using Linked Server From ABAP

    Hello,
    I am experiencing a head-scratcher of a problem when trying to use a Linked Server connection to query a remote SQL Server database from our R/3 system.  We have had this working just fine for some time, but after migrating to new hardware and upgrading OS, DBMS, and R/3, now we are running into problems.
    The target database is a named instance on SQL Server 2000 SP3, Windows 2000 Server.  The original source R/3 system was 4.7x2.00, also on SQL Server 2000 (SP4), Windows 2000 Server.  I had been using a Linked Server defined via SQL Enterprise Manager (actually defined when the source was on SQL Server 7), which called an alias defined with the Client Network Utility that pointed to the remote named instance.  This alias and Linked Server worked great for several years.
    Now we have migrated our R/3 system onto new hardware, running Windows Server 2003 SP1 and SQL Server 2005 SP1.  The application itself has been upgraded to ECC 6.0.  I performed the migration with a homogeneous system copy, and everything has worked just fine.  I redefined the Linked Server on the new SQL 2005 installation, this time avoiding the alias and referencing the remote named instance directly, and it tests out just fine using queries from SQL Management Studio.  It also tests fine with OSQL called from the R/3 server console, both when logged on as SAPServiceSID with a trusted connection, and with a SQL login as the schema owner (i.e., 'sid' in lowercase).  From outside of R/3, I cannot make it fail.  It works perfectly.
    That all changes when I try to use the Linked Server within an ABAP application, however.  The basic code in use is
    EXEC SQL.
       SET XACT_ABORT ON
       DELETE FROM [SERVER\INSTANCE].DATABASE.dbo.TABLE
    ENDEXEC.
    The only thing different about this code from that before the upgrade/migration is the reference to [SERVER\INSTANCE] which previously used the alias of just SERVER.
    The program short dumps with runtime error DBIF_DSQL2_SQL_ERROR, exception CX_SY_NATIVE_SQL_ERROR.  The database error code is 15274, and the error text is "Access to the remote server is denied because the current security context is not trusted."
    I have set the "trustworthy" property on the R/3 database, I have ensured SAPServiceSID is a member of the sysadmin SQL role, I've even made it a member of the local Administrators group on both source and target servers, and I've done the same with the SQL Server service account (it uses a domain account).  I have configured the Distributed Transaction Coordinator on the source (Win2003) system per Microsoft KB 839279 (this fixed problems with remote queries coming the other way from the SQL2000 system), and I've upgraded the system stored procedures on the target (SQL2000) system according to MS KB 906954.  I also tried making the schema user a member of the sysadmin role, but naturally that was disastrous, resulting in an instant R/3 crash (don't try this in production!), so I set it back the way it was (default).
    What's really strange is no matter how I try this from outside the R/3 system, it works perfectly, but from within R/3 it does not.  A search of SAP Notes, SDN forums, SAPFANS, Microsoft's KnowledgeBase, and MSDN Forums has not yielded quite the same problem (although that did lead me to learning about the "trustworthy" database property).
    Any insight someone could offer on this thorny problem would be most appreciated.
    Best regards,
    Matt

    Good news! We have got it to work. However, we did it in something of
    a backwards way, and I'm sure you'll laugh when you see how it was done. Also, the solution depends upon the fact that the remote server is still using SQL Server 2000, and so doesn't have quite so many restrictions placed upon it for distributed transactions and Linked Servers as SQL Server 2005 now does.
    At the heart of the solution is the fact that the Linked Server coming FROM the remote server TO our SAP system works fine. Finally, coupled with the knowledge that using DBCON on the SAP side to the remote server also does actually provide a connection (see Notes 323151 and 738371), we set up a roundabout way of achieving our goal. In essence, from ABAP, we set up the DBCON connection to the remote server, at which point all the Native SQL commands execute in the context of the remote server. From within that connection, we
    reference the tables in SAP via the Linked Server defined on the remote
    server, as if SAP were the remote server, selecting data from SAP and inserting it into the remote (but apparently local to this connection) tables.
    So, to spell it out, we define a Linked Server on the remote server pointing back to the SAP server as SAPSERV, with a SQL login mapping defined on the remote system pointing back to a SQL login in the SAP database. We also define a connection to the remote server from SAP using DBCON, using that remote SQL login for authentication.
    Then, in our ABAP code, we simply do something along the lines of
    exec sql.
       set connection 'REMOTE'
    endexec.
    exec sql.
       connect to 'REMOTE'
    endexec.
    exec sql.
       insert into REMOTE_TABLE
          select * from SAPSERV.SID.sid.SAP_TABLE
    endexec.
    exec sql.
       commit
    endexec.
    exec sql.
       disconnect 'REMOTE'
    endexec.
    This is, of course, a test program, but it demonstrated that it worked,
    and we were able to see that entries were appropriately deleted and inserted in the remote server's table. The actual program for use is a little more complex, in that there are about four different operations at different times, and we had to resolve the fact that the temp table SAP_TABLE was being held in a lock by our program, resulting in a deadly embrace, but our developer was able to work that out, and all is now well.
    I don't know if this solution will have applicability to any other customers, but it works for us, for now.
    SAPSERV, REMOTE, REMOTE_TABLE, and SAP_TABLE are, of course, placeholder names, not the actual server or table names, so as not to confuse anyone.
    Best regards,
    Matt

Maybe you are looking for