Problem accessing DB from Custom RoleMapper - Weblogic

This is a discussion on Problem accessing DB from Custom RoleMapper - Weblogic ; I've built a custom implementation of the RoleMapper class, and everything works fine except for one thing... when the server is booted, I must first access the WL console in order for the RoleMapper to be called, else the WL ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Problem accessing DB from Custom RoleMapper

  1. Problem accessing DB from Custom RoleMapper



    I've built a custom implementation of the RoleMapper class, and everything works
    fine except for one thing... when the server is booted, I must first access the
    WL console in order for the RoleMapper to be called, else the WL server crashes
    back to a command prompt with no error log messages ... complete WL failure.

    A little history on how it works - basically, the code is taken from the WL8 RoleMapper
    example posted on dev2dev. However, in my RoleMapperDatabase class, I have code
    to connect to an oracle database to retrieve the roles. Whenever a lookup is
    done, I try to grab a DataSource object from the JNDI tree, and as soon as I get
    a valid one I cache it in the class for future use. This gets around the problem
    of failure when the server is first coming up, because the rolemapper initialize
    gets called before the db datasource is bound to the jndi tree. the lookup is
    pretty standard, something like:
    ic.lookup("dsROLESDB")

    This call works fine, as long as the first time its hit is from the WL console.
    If I start WL server, then hit another webapp which causes a role lookup to happen,
    the ic.lookup line fails to the point of crashing the server. Im assuming the
    problem fix has something to do with being logged in as admin when the call happens,
    but Im not sure... either way it shouldnt bring down the whole server...

    Does anyone have any suggestions on implementing database access from within a
    rolemapper?

    Thanks in advance...

    Chris



  2. Re: Problem accessing DB from Custom RoleMapper


    "Chris" wrote in message
    news:3f97f9fb$1@newsgroups.bea.com...
    >
    >
    > I've built a custom implementation of the RoleMapper class, and everything

    works
    > fine except for one thing... when the server is booted, I must first

    access the
    > WL console in order for the RoleMapper to be called, else the WL server

    crashes
    > back to a command prompt with no error log messages ... complete WL

    failure.
    >
    > A little history on how it works - basically, the code is taken from the

    WL8 RoleMapper
    > example posted on dev2dev. However, in my RoleMapperDatabase class, I

    have code
    > to connect to an oracle database to retrieve the roles. Whenever a lookup

    is
    > done, I try to grab a DataSource object from the JNDI tree, and as soon as

    I get
    > a valid one I cache it in the class for future use. This gets around the

    problem
    > of failure when the server is first coming up, because the rolemapper

    initialize
    > gets called before the db datasource is bound to the jndi tree. the

    lookup is
    > pretty standard, something like:
    > ic.lookup("dsROLESDB")
    >
    > This call works fine, as long as the first time its hit is from the WL

    console.
    > If I start WL server, then hit another webapp which causes a role lookup

    to happen,
    > the ic.lookup line fails to the point of crashing the server. Im assuming

    the
    > problem fix has something to do with being logged in as admin when the

    call happens,
    > but Im not sure... either way it shouldnt bring down the whole server...
    >


    By calling ic.lookup, you are most likely creating a recursive situation as
    ic.lookup is going
    to require security to be evaluated which is going to come back to your role
    mapper.
    You may be able to utilize the identity from initialization and then do a
    runAs before
    invoking the ic.lookup. We are thinking about having the security provider
    code always invoked
    with kernel identity.



  3. Re: Problem accessing DB from Custom RoleMapper


    Thanks for the response back, but unfortunately Im not in a loop. I was
    stuck in the loop last week before I figured out I needed to exclude all
    JDBC resource calls and get out of the problem you are referring to:

    1 - request for a resource requires role lookup from db
    2 - make a datasource object, call out to database to find roles
    3 - calling out to database requires role lookup, go to 1

    Took me the better part of a day trying to figure out what was going on, and
    when I finally did, I felt like a moron for not seeing it sooner.

    Anyway, with the latest problem.... I have a small workaround by first
    checking the resource type, and if it is JNDI or JDBC I skip out and return
    an empty role set, because I really dont care to attach roles there anyway
    (mostly need the roles for EJBs and WebApps). However, I hate workarounds,
    and would like to fix this properly. Im not overly familiar with the JAAS
    stuff, and the identity you are referring to... is there anyway you could
    post some sample code snippets, or point me to a good reference in the API??
    Im not sure where I get the identity from initialization you are referring
    to.

    I tried writing a PrivilegeAction, and putting the ic lookup from within
    there, but I had no Subject to call the doAs from, so it was a nonstarter...
    is this the route you are suggesting, or am I misunderstanding.

    Thanks for the help - to be honest I wasnt expecting to get any bites from
    this post... doesnt sound like too many people are taking advantage of this
    WLS feature, but it is critical to our enterprise infrastructure.

    Chris


    "Peter" wrote in message news:3f97ff4d@newsgroups.bea.com...

    > > ic.lookup("dsROLESDB")


    > By calling ic.lookup, you are most likely creating a recursive situation

    as
    > ic.lookup is going
    > to require security to be evaluated which is going to come back to your

    role
    > mapper.
    > You may be able to utilize the identity from initialization and then do a
    > runAs before
    > invoking the ic.lookup. We are thinking about having the security provider
    > code always invoked
    > with kernel identity.





  4. Re: Problem accessing DB from Custom RoleMapper


    "Chris Hettinger" wrote in message
    news:3f983b06@newsgroups.bea.com...
    >
    > Thanks for the response back, but unfortunately Im not in a loop. I was
    > stuck in the loop last week before I figured out I needed to exclude all
    > JDBC resource calls and get out of the problem you are referring to:
    >
    > 1 - request for a resource requires role lookup from db
    > 2 - make a datasource object, call out to database to find roles
    > 3 - calling out to database requires role lookup, go to 1
    >
    > Took me the better part of a day trying to figure out what was going on,

    and
    > when I finally did, I felt like a moron for not seeing it sooner.
    >
    > Anyway, with the latest problem.... I have a small workaround by first
    > checking the resource type, and if it is JNDI or JDBC I skip out and

    return
    > an empty role set, because I really dont care to attach roles there anyway
    > (mostly need the roles for EJBs and WebApps). However, I hate

    workarounds,
    > and would like to fix this properly. Im not overly familiar with the JAAS
    > stuff, and the identity you are referring to... is there anyway you could
    > post some sample code snippets, or point me to a good reference in the

    API??
    > Im not sure where I get the identity from initialization you are referring
    > to.
    >
    > I tried writing a PrivilegeAction, and putting the ic lookup from within
    > there, but I had no Subject to call the doAs from, so it was a

    nonstarter...
    > is this the route you are suggesting, or am I misunderstanding.
    >

    Try getting the current subject from initialization.




+ Reply to Thread