Discussions

News: BEA Launches WebLogic Enterprise Security

  1. BEA Launches WebLogic Enterprise Security (16 messages)

    BEA today announced WebLogic Enterprise Security (WLES), an application security infrastructure product that allows centralized policy control and visibility but features a distributed architecture that doesn't hinder application performance. WLES' features include authentication, identity assertion, credential mapping, dynamic role mapping, rules-based parametric authorization, etc.

    The initial product will be released at the end of the month and will support WebLogic Server, with next years releases supporting Websphere and .NET.

    Read BEA Fills the Gap in Application Security with BEA WebLogic Enterprise Security(press release).
    Data sheet (PDF).
    BEA jumps on security bandwagon (ZDNET)

    Threaded Messages (16)

  2. This is still missing in J2EE[ Go to top ]

    I'd like to see the J2EE standard include APIs for creating users/groups programatically. As it is today, you'll have to modify the underlying datastructure in order to add users or groups (roles).
    There is also no support for securing your data, only methods. A way of integrating ACLs with J2EE would be nice.
    As it is now, we have made our own hacks to solve these problems. My opinion is that the J2EE standard should add support for this, as there is a need for it.
  3. This is still missing in J2EE[ Go to top ]

    In fact, the absence of instance level security is quite a problem in the J2EE area. Does anybody now which tools/frameworks to use in order to handle this problem?
  4. What exactly do you mean by instance level security ?
    Are you lookin for security at EJB method level? like allowing access to a specific method of an EJB to only users with a certain role?
  5. thinking about securing EJB instanes (data base rows).
    imagine having an entity bean that deals with bank accounts.
    so you can easily use class (or method level security) to allow just users in certain roles to update accounts.
    but how can you just allow access for a logged in user to a crertain account
    (= a certain entity bean instance)?.

    what tools to use to achieve this?
  6. Row level security?[ Go to top ]

    thinking about securing EJB instanes (data base rows).

    > imagine having an entity bean that deals with bank accounts.
    > so you can easily use class (or method level security) to allow just users in certain roles to update accounts.
    > but how can you just allow access for a logged in user to a crertain account
    > (= a certain entity bean instance)?.
    >
    > what tools to use to achieve this?

    I would use a tool called 'business logic' (sometimes called 'code') ;)

    But seriously, I wouldn't want to see this kind of constraints implemented outside the application logic.

    //ras
  7. Row level security?[ Go to top ]

    I would use a tool called 'business logic' (sometimes called 'code') ;)

    >
    > But seriously, I wouldn't want to see this kind of constraints implemented outside the application logic.
    >
    > //ras

    You wouldnt want to write humongous application logic to determine authorization credentials for an application/part of application. Think about the case where the enterprise security policy is very fine grained and the access roles are nested in a complex aplication ..you would want to have such applications' security to be taken care of externally ..by building a proper LDAP heirarchy (as this speeds up the search functionality) and mapping the roles to user groups. This gives more control in not only providing access/authorization criteria, but also in administering the users. Believe me, in huge organization, it is the administration part which makes the tools like Netegrity/RSA/Oblix worth their money.
  8. thinking about securing EJB instanes (data base rows).

    > imagine having an entity bean that deals with bank accounts.
    > so you can easily use class (or method level security) to allow just users in certain roles to update accounts.
    > but how can you just allow access for a logged in user to a crertain account
    > (= a certain entity bean instance)?.
    >
    > what tools to use to achieve this?

    There are tools that can be used to achieve this like Netegrity's Application server agents. If you are familiar with Enterprise SSO products like Netegrity, RSA and Oblix, they typically come with application server agents. These app server agents are typically J2EE modules sitting on the app-server(s) which is(are) hosting the applications and they can be configured so that whenever there is a hit on a specific EJB or a method of an EJB, then it will look to its policy server to determine the authorization credentials for this user and either let the user access it, or re-direct him to a specific page.
    RSA cleartrust also provides this functionality, but i think there is a ot of custom coding needed for cleartrust to achieve this.
    But remember, these products are very expensive in their licensing structure(its a tiered pricing structure, which starts with per DN entry in LDAP and as the number of entries increases the cost comes dwon) ..and that is where i think BEA can add value by providing the WLES with the above mentioned functionalitites to its current clients. It can definitely make a dent there to the curent players.
  9. This is still missing in J2EE[ Go to top ]

    thinking about securing EJB instanes (data base rows).

    > imagine having an entity bean that deals with bank accounts.
    > so you can easily use class (or method level security) to allow just users in certain roles to update accounts.
    > but how can you just allow access for a logged in user to a crertain account
    > (= a certain entity bean instance)?.
    >
    > what tools to use to achieve this?

    I think you're right, the absence of instance level security is quite a problem.

    Sounds like you are going through the same pain I did 18 months ago.
    I've heard of many people hitting the same problem you have too. Haven't seen many solutions though. This is how I did it:

    I was on a team providing a base set of components on which a number of applications were to be built. This included a basic MVC achitecture and stateless session beans. Database access was through jdbc. My area was Security.

    Our Users wanted role assignments to consist of a functional and information part e.g they wanted to setup users that could perform functions on selective data entities. In you example, they may want userX to be able to 'view accounts'
    for say personal and business accounts but only 'modify account' for personal accounts.


    To implement this we :

    Used LDAP for the roles / user membership

    Used a db table to hold user/role to Account type mapping

    Used one of the previously mentioned Security products to authorise a user to a url and add to http request the role names that allowed the authorisation to succeed (in the form of http header variables ).

    Coded the Controller Servlet of our MVC architecture to cature these header variables and store them as objects (strings) in a 'RequestContext' object.


    This RequestContext instance is then passed down the call stack until an authorisation decision is to be made.

    Two types of decision can be made :

     For view accounts, the app is going to list all accounts user is authorised to.
    The app calls the getAuthorisedEntities method on our security ejb ( stateless session ) passing in "Account" and the requestContext. The security ejb gets the username through the use of EJBContext.getCallerPrincipal and together
    with the roles held in the requestContext retrieves the valid account types for the user / function. The app then uses this list to select only valid accounts.

     For modify account, the app will persist the user's some sort of change of the account. In this scenario the app will call the security bean's method 'authorise' passing in the account ( or at least account type ) and the requestContext. This time the security bean obtains the account's Account type and again using the username and roles in the requestContext ensures a mapping
    exists on the mapping db table. If no mapping exists an exception is thrown which ripples back up to the controller servlet which redirects to a not authorised page.


    I'm sure there is some drawbacks with this solution and only Weblogic 6.1 was around at the time. Hope at least it gives you some ideas.
  10. This is still missing in J2EE[ Go to top ]

    Thanx for your info.
    This is, roughly, the same way how we solved the problem (we still have perfromance problems in case of mass data here ...)
    But I'm still wondering why this issue is not addressed in the spec and why there's no framework available.
    Lot's of people do need row level security and it's always painfull building 'standard' stuff by oneself.
  11. This is still missing in J2EE[ Go to top ]

    No prob

    I guess this is the gap WLES aims to fill. I've seen the sales pitch for weblogic 7 security and I must admit I was impressed although I wasn't 100% sure it would solve the instance based problem we were discussing.
  12. How does it work...[ Go to top ]

    The data sheet basically shows the technology used in WebLogic Server since version 7.0. Since the infrastructure relies on a "user store" and a "security store" it would be interesting to see, how the applications actually interact with the stores. I would assume that they do not use a central service layer to connect to the stores, but that they connect directly for performance reasons.
    This raises some important questions:

    - How are changes in policy/group memberships propagatated to the clients of the service - they would certainly use some local cache to perform there tasks
    - Is datastore failover handled (gracefully)?
    - How are the infrastructure clients configured?
    - How do the infrastructure clients establish trust with the security infrastructure?
    - Can applications create temporary policies on the fly? Can they be shared with other applications?
  13. A little late to the game ..[ Go to top ]

    Enterprise security as a market is growing rapidly, since the last 2-3 years. With already a number of established players (like Neterity (Siteminder and Identity Minder), RSA Clear Trust, Oblix netpoint, IBM Tivoli to name a few top leaders), I think BEA is a bit late to the game. But it can see some success by selling this WLES as an add-on to its current clients if they are implementing Enterprise security as all the above listed products are a bit pricey in their licensing. According to Gartner's magic quadrant, Netegrity is currently leading the pack in this area.

    --Jagan
  14. A little late to the game ..[ Go to top ]

    I would suspect there is more to this security package than the basic stuff available with WLS. I remember BEA aquired security vendor Crosslogix last year who competed with Netegrity and others.
  15. How does it work...[ Go to top ]

    How about the dynamic role mapping and rules based parametric authorization, has this been in WLS since 7.0?

    As far as I can see, this is a big step towards true multi-channel security.

    - AM
  16. JAAS?[ Go to top ]

    No mention of JAAS anywhere! Does this support JAAS? build on it? not even use it? WL7 had sort of implemented JAAS, with a few proprietary additions. WL5 had an entire proprietary security layer also, that was a nightmare when you had to get off of WL5. SO much for write once, run anywhere.
  17. One of the problems with WebLogic's solution is that it only supports WebLogic.

    JoshuaBranch AS supports all J2EE servers by installing the central service in JBoss, while permitting client applications to be installed in any J2EE container (JBoss, WebSphere, etc,...) JNDI is a beautiful problem solver.

    There are some things that I see preventing this type of solution from being a J2EE standard anytime soon. Thus far, the concept of creating a J2EE standard where the service is not necessarily provided by the immediate container is a bit new. This is common for J2EE applications, since it was created to support distributed computing. I just haven't seen proposals for a J2EE standard that requires a container service to is a different container to fulfill its requests. Until then, there will be a demand for third-party centralized solutions.