Could this be the reason?

11 views
Skip to first unread message

Nancy Anthracite

unread,
Dec 19, 2011, 10:28:21 PM12/19/11
to Solomon Blaz, vista-emer...@googlegroups.com, ehs_h...@googlegroups.com
gtm:/home/nancy# cat /var/lib/tomcat6/webapps/main/WEB-INF/config/security-
config.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:security="http://www.springframework.org/schema/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:util="http://www.springframework.org/schema/util"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/security
http://www.springframework.org/schema/security/spring-security-2.0.4.xsd
http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util-2.0.xsd">

<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:strings.properties"/>
</bean>

<security:http entry-point-ref="formAuthenticationEntryPoint" access-
denied-page="/login.html?error=true">
<security:intercept-url pattern="/about.html"
access="IS_AUTHENTICATED_ANONYMOUSLY"/>
<security:intercept-url pattern="/login.html*"
access="IS_AUTHENTICATED_ANONYMOUSLY"/>
<security:intercept-url pattern="/logout.html*" filters="none"/>

<security:intercept-url pattern="/**/*.swf" access="ROLE_USER"/>
<security:intercept-url pattern="/**/*.xml" access="ROLE_USER"/>
<security:intercept-url pattern="/**/*.html" access="ROLE_USER"/>

<security:anonymous/>
</security:http>

<security:authentication-manager alias="authenticationManager"/>

<bean id="vistaAuthenticationProvider"
class="gov.va.med.edp.springframework.security.providers.vistalink.VistaAuthenticationProvider">
<security:custom-authentication-provider/>
<property name="userDetailsService" ref="vistaUserDetailsDao"/>
</bean>

<bean id="vistaUserDetailsDao"
class="gov.va.med.edp.springframework.security.userdetails.vistalink.VistaLinkUserDetailService">
<property name="applicationName" value="${app.name}"/>
<property name="rpcTemplate" ref="vistaLinkRpcTemplate"/>
</bean>

<bean id="formAuthenticationProcessingFilter"
class="gov.va.med.edp.springframework.security.ui.vistalink.VistaAuthenticationProcessingFilter">
<security:custom-filter position="AUTHENTICATION_PROCESSING_FILTER"/>
<property name="authenticationManager" ref="authenticationManager"/>
<property name="defaultTargetUrl" value="/"/>
</bean>

<bean id="formAuthenticationEntryPoint"
class="org.springframework.security.ui.webapp.AuthenticationProcessingFilterEntryPoint">
<property name="loginFormUrl" value="/login.html"/>
</bean>

<bean id="logoutFilter"
class="org.springframework.security.ui.logout.LogoutFilter">
<constructor-arg value="/"/>
<constructor-arg>
<list>
<bean
class="gov.va.med.edp.springframework.security.ui.vistalink.VistaLogoutHandler">
<property name="userDetailsService"
ref="vistaUserDetailsDao"/>
</bean>
<bean
class="org.springframework.security.ui.logout.SecurityContextLogoutHandler"/>
</list>
</constructor-arg>
<property name="filterProcessesUrl" value="/logout.html"/>
</bean>
</beans>gtm:/home/nancy#


On Monday, December 19, 2011, Nancy Anthracite wrote:
> We only found
> XUS KAAJEE GET USER INFO
> XUS KAAJEE LOGOUT


--
Nancy Anthracite

Solomon Blaz

unread,
Dec 20, 2011, 11:10:18 AM12/20/11
to nanth...@earthlink.net, vista-emer...@googlegroups.com, ehs_h...@googlegroups.com
At first glance, that looks correct to me... I'd suggest running EDIS with a debugger open and breaking in the VistaUserDetailService to see if anything suspicious is happening.

The logs from yesterday's experiments looked like VistALink was letting us in as DUZ=14 no matter the access/verify codes, which definitely shouldn't happen. ;)

Are there any mods to the M side of VistALink that might be allowing this to occur?

I'm planning on upgrading EDIS to VistALink 1.6 tonight as we think that might help with debugging.

Nancy Anthracite

unread,
Dec 20, 2011, 11:21:31 AM12/20/11
to vista-emer...@googlegroups.com, Solomon Blaz, ehs_h...@googlegroups.com
Solomon, on the surface it looks like any user is automatically authorized to
proceed, which is what we were wondering about. What is this
access="IS_AUTHENTICATED_ANONYMOUSLY" authorizing?

Nancy Anthracite

unread,
Dec 21, 2011, 11:38:19 AM12/21/11
to vista-emer...@googlegroups.com, Solomon Blaz, ehs_h...@googlegroups.com
OK, I have been thinking - as dangerous as that can be, for at least a
temporary fix so this can get used ...

Could it be that this lets everybody in after they have authenticated with
KAYJEE and because it is bypassing KAAJEE we have left out the authentication
part?

And even if that is not the case, what about restricting access to this login
page so that only those who have previously authenticated, say by logging in
using an EWD log-in for VistA or by signing in to CPRS first and getting there
by a tools menu item restricted to those with a certain key or by accessing
through a restricted proxy server?

I suspect that my muddy thinking might spark a good solution thought among
those that know what they are talking about when it comes to all of this.

Oroville has offered to help and they have a couple of very good EWD
programmers working with them, so I think they could help with this if this
makes sense.

--
Nancy Anthracite

On Tuesday, December 20, 2011, Solomon Blaz wrote:

Solomon Blaz

unread,
Dec 21, 2011, 12:23:32 PM12/21/11
to nanth...@earthlink.net, vista-emer...@googlegroups.com
Oh! I can see why you might be confused by that. If you look
carefully, you'll see the IS_AUTHENTICATED_ANONYMOUSLY is being
applied to 2 web pages in the application:

/about.html
/login.html

which is exactly what we want, those pages need to be able to to be
visited before a user has signed in. All the rest of the application
requires an authenticated user with ROLE_USER, which is granted when a
successful VistA sign on has occurred.

If you care to climb the learning curve, you can learn about
spring-security and its configuration here:
http://static.springsource.org/spring-security/site/

Nancy Anthracite

unread,
Dec 21, 2011, 12:34:02 PM12/21/11
to ehs_h...@googlegroups.com, vista-emer...@googlegroups.com, Solomon Blaz
Solomon's tester now works since the fixes Wasim put in on our server!

See the attached txt file.

So now I wonder if we can use this to test the RPC that is supposed to be
being used for this authentication this way somehow? I know Solomon told me I
could change out the RPC XOBV TEST STRING for a different one. In fact, I
picked this one when we were trying to figure out what was happening and why
VistALink testing was working but not EDIS and I wanted to compare the two
outputs.

So, what is being called to authenticate the user? An RPC and if an RPC,
which one, XUS KAAJEE GET USER INFO ?

On Wednesday, December 21, 2011, Nancy Anthracite wrote:
> OK, I have been thinking - as dangerous as that can be, for at least a
> temporary fix so this can get used ...
>
> Could it be that this lets everybody in after they have authenticated with
> KAYJEE and because it is bypassing KAAJEE we have left out the
> authentication part?
>
> And even if that is not the case, what about restricting access to this
> login page so that only those who have previously authenticated, say by
> logging in using an EWD log-in for VistA or by signing in to CPRS first
> and getting there by a tools menu item restricted to those with a certain
> key or by accessing through a restricted proxy server?
>
> I suspect that my muddy thinking might spark a good solution thought among
> those that know what they are talking about when it comes to all of this.
>
> Oroville has offered to help and they have a couple of very good EWD
> programmers working with them, so I think they could help with this if this
> makes sense.
>

> > At first glance, that looks correct to me... I'd suggest running EDIS
> > with a debugger open and breaking in the VistaUserDetailService to see
> > if anything suspicious is happening.
> >
> > The logs from yesterday's experiments looked like VistALink was letting
> > us in as DUZ=14 no matter the access/verify codes, which definitely
> > shouldn't happen. ;)
> >
> > Are there any mods to the M side of VistALink that might be allowing this
> > to occur?
> >
> > I'm planning on upgrading EDIS to VistALink 1.6 tonight as we think that
> > might help with debugging.
> >
> > On Dec 19, 2011, at 8:28 PM, Nancy Anthracite <nanth...@earthlink.net>
>
> wrote:
> > > gtm:/home/nancy# cat
> > > /var/lib/tomcat6/webapps/main/WEB-INF/config/security- config.xml
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <beans xmlns="http://www.springframework.org/schema/beans"
> > >
> > > xmlns:security="http://www.springframework.org/schema/security"
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > >
> > > xmlns:util="http://www.springframework.org/schema/util"
> > >
> > > xsi:schemaLocation="http://www.springframework.org/schema/beans
> > >
> > > http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> > >
> > > http://www.springframework.org/schema/security
> > >
> > > http://www.springframework.org/schema/security/spring-security-2.0.4.xs

> > > d http://www.springframework.org/schema/util


> > > http://www.springframework.org/schema/util/spring-util-2.0.xsd">
> > >
> > > <bean
> > >
> > > class="org.springframework.beans.factory.config.PropertyPlaceholderConf

> > > ig urer">


> > >
> > > <property name="location" value="classpath:strings.properties"/>
> > >
> > > </bean>
> > >
> > > <security:http entry-point-ref="formAuthenticationEntryPoint" access-
> > >
> > > denied-page="/login.html?error=true">
> > >
> > > <security:intercept-url pattern="/about.html"
> > >
> > > access="IS_AUTHENTICATED_ANONYMOUSLY"/>
> > >
> > > <security:intercept-url pattern="/login.html*"
> > >
> > > access="IS_AUTHENTICATED_ANONYMOUSLY"/>
> > >
> > > <security:intercept-url pattern="/logout.html*" filters="none"/>
> > >
> > > <security:intercept-url pattern="/**/*.swf" access="ROLE_USER"/>
> > > <security:intercept-url pattern="/**/*.xml" access="ROLE_USER"/>
> > > <security:intercept-url pattern="/**/*.html" access="ROLE_USER"/>
> > >
> > > <security:anonymous/>
> > >
> > > </security:http>
> > >
> > > <security:authentication-manager alias="authenticationManager"/>
> > >
> > > <bean id="vistaAuthenticationProvider"
> > >
> > > class="gov.va.med.edp.springframework.security.providers.vistal

> > > in k.VistaAuthenticationProvider">


> > >
> > > <security:custom-authentication-provider/>
> > > <property name="userDetailsService" ref="vistaUserDetailsDao"/>
> > >
> > > </bean>
> > >
> > > <bean id="vistaUserDetailsDao"
> > >
> > > class="gov.va.med.edp.springframework.security.userdetails.vist

> > > al ink.VistaLinkUserDetailService">


> > >
> > > <property name="applicationName" value="${app.name}"/>
> > > <property name="rpcTemplate" ref="vistaLinkRpcTemplate"/>
> > >
> > > </bean>
> > >
> > > <bean id="formAuthenticationProcessingFilter"
> > >
> > > class="gov.va.med.edp.springframework.security.ui.vistalink.Vis

> > > ta AuthenticationProcessingFilter">


> > >
> > > <security:custom-filter
> > > position="AUTHENTICATION_PROCESSING_FILTER"/> <property
> > > name="authenticationManager" ref="authenticationManager"/>
> > > <property name="defaultTargetUrl" value="/"/>
> > >
> > > </bean>
> > >
> > > <bean id="formAuthenticationEntryPoint"
> > >
> > > class="org.springframework.security.ui.webapp.AuthenticationPro

> > > ce ssingFilterEntryPoint">


> > >
> > > <property name="loginFormUrl" value="/login.html"/>
> > >
> > > </bean>
> > >
> > > <bean id="logoutFilter"
> > >
> > > class="org.springframework.security.ui.logout.LogoutFilter">
> > >
> > > <constructor-arg value="/"/>
> > > <constructor-arg>
> > >
> > > <list>
> > >
> > > <bean
> > >
> > > class="gov.va.med.edp.springframework.security.ui.vistalink.VistaLogout

> > > Ha ndler">


> > >
> > > <property name="userDetailsService"
> > >
> > > ref="vistaUserDetailsDao"/>
> > >
> > > </bean>
> > > <bean
> > >
> > > class="org.springframework.security.ui.logout.SecurityContextLogoutHand

> > > le r"/>


> > >
> > > </list>
> > >
> > > </constructor-arg>
> > > <property name="filterProcessesUrl" value="/logout.html"/>
> > >
> > > </bean>
> > >
> > > </beans>gtm:/home/nancy#
> > >
> > > On Monday, December 19, 2011, Nancy Anthracite wrote:
> > >> We only found
> > >> XUS KAAJEE GET USER INFO
> > >> XUS KAAJEE LOGOUT


--
Nancy Anthracite

SolomonsTesterForEDIS-VistALink.txt

Solomon Blaz

unread,
Dec 21, 2011, 12:42:29 PM12/21/11
to nanth...@earthlink.net, ehs_h...@googlegroups.com, vista-emer...@googlegroups.com
Yes, XUS KAAJEE GET USER INFO authenticates the user.

Nancy Anthracite

unread,
Dec 21, 2011, 12:52:54 PM12/21/11
to Solomon Blaz, ehs_h...@googlegroups.com, vista-emer...@googlegroups.com
OK, one thing I see that needs to be checked out right off the back is "get
permitted divisions" in the routine.

The routine is very nicely commented!

See the attached text file with the RPC listing at the routine, with and
without line numbers so we can talk about it on the email an be on the same
page. I put it in a text file to avoid the dreaded line wraps in email.

> >> > > .xs d http://www.springframework.org/schema/util


> >> > > http://www.springframework.org/schema/util/spring-util-2.0.xsd">
> >> > >
> >> > > <bean
> >> > >
> >> > > class="org.springframework.beans.factory.config.PropertyPlaceholderC

> >> > > onf ig urer">

> >> > > out Ha ndler">


> >> > >
> >> > > <property name="userDetailsService"
> >> > >
> >> > > ref="vistaUserDetailsDao"/>
> >> > >
> >> > > </bean>
> >> > > <bean
> >> > >
> >> > > class="org.springframework.security.ui.logout.SecurityContextLogoutH

> >> > > and le r"/>


> >> > >
> >> > > </list>
> >> > >
> >> > > </constructor-arg>
> >> > > <property name="filterProcessesUrl" value="/logout.html"/>
> >> > >
> >> > > </bean>
> >> > >
> >> > > </beans>gtm:/home/nancy#
> >> > >
> >> > > On Monday, December 19, 2011, Nancy Anthracite wrote:
> >> > >> We only found
> >> > >> XUS KAAJEE GET USER INFO
> >> > >> XUS KAAJEE LOGOUT
> >
> > --
> > Nancy Anthracite


--
Nancy Anthracite

EDIS-User-Login-Authentication-RPC.txt

Wasim Naffar

unread,
Dec 22, 2011, 10:40:12 AM12/22/11
to vista-emer...@googlegroups.com

Finally :):) we catch where is the problem and we solved it from the GT.M side ;), and just we are finalizing, preparing and testing the whole solution.

Have a nice weekend all...

Cheers,
Wasim




--
You received this message because you are subscribed to the Google Groups "VistA Emergency Room" group.
To post to this group, send email to vista-emer...@googlegroups.com.
To unsubscribe from this group, send email to vista-emergency-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/vista-emergency-room?hl=en.


Feras Kamal

unread,
Dec 22, 2011, 10:47:47 AM12/22/11
to vista-emer...@googlegroups.com

Great news to hear ….congratulations to everybody and special thanks to our friends Nancy and Solomon for their continuous support.

 

Best

Feras

Nancy Anthracite

unread,
Dec 22, 2011, 11:27:00 AM12/22/11
to vista-emer...@googlegroups.com, Wasim Naffar
Wonderful! Don't leave us in suspense. What was it?

What a great holiday gift! I am really HAPPY about it. :-)

You folks should be showing this off at the VistA Community Meeting!!


--
Nancy Anthracite

Solomon Blaz

unread,
Dec 22, 2011, 8:48:53 PM12/22/11
to vista-emer...@googlegroups.com, Wasim Naffar
Hoorah!

I think this calls for some more dancing in the streets. A bit cold
for it here in Salt Lake City, maybe, though. Maybe I could dance a
bit on my snowboard sliding down the mountain. ;)

Great work everyone!

Sincerely,
Solomon

On Thu, Dec 22, 2011 at 9:27 AM, Nancy Anthracite

Khamis Siksek

unread,
Dec 23, 2011, 5:36:53 AM12/23/11
to vista-emer...@googlegroups.com
:-)

This is our holidays gift from Jordan courtesy of Ahmad Sharaf and Wasim Naffar

Hope you enjoy your holidays and Nancy, the idea of presenting EDIS in VCM looks tempting :-)

Khamis Siksek
http://saksoook.blogspot.com

Nancy Anthracite

unread,
Dec 23, 2011, 8:48:46 AM12/23/11
to vista-emer...@googlegroups.com
Count on presenting at the VCM. Just tell me who is going to be talking and
you will be on the schedule in a flash. I want the VistA Community to know
about this!

skip ormsby

unread,
Dec 23, 2011, 9:22:44 AM12/23/11
to vista-emer...@googlegroups.com
I was doing the down loads for BUILD 2010 03.0 and saw this informational patch, maybe is will be of some help.
XOBV-1P5_SEQ-2_PAT-2.TXT

Nancy Anthracite

unread,
Dec 23, 2011, 9:54:05 AM12/23/11
to vista-emer...@googlegroups.com, skip ormsby
Yes, I saw this which is one of the reasons I was not in a hurry to try to
upgrade to VistALink 1.6. Since they are using a central server, I wanted to
know what that would mean to us first. With the direction the VA is moving
things, I am suspicious about what the new VistALink update contains.

Wasim Naffar

unread,
Dec 27, 2011, 7:42:57 AM12/27/11
to vista-emer...@googlegroups.com
Hi Nancy,
We installed and tested the new patch 'UJO*1.0*123' in your server which contains the last fix of the authentication problem. You can find the UJO_0100_seq001_pat123.kids file in /tmp/.
The problem was in losing of RPC parameters inside the  XOBSRA1 routine, therefore after New'ing the RPC parameters in it we preserve the parameter's Value, and that solved the problem.

Check EDIS at your server and enjoy ;)

Regards,
Wasim

Nancy Anthracite

unread,
Dec 27, 2011, 11:13:50 AM12/27/11
to vista-emer...@googlegroups.com, Wasim Naffar
Thank you! I will go get it and give it to George Lilly to post on the trac
server.

On Tuesday, December 27, 2011, Wasim Naffar wrote:
> Hi Nancy,

> We installed and tested the new patch '*UJO*1.0*123*' in your server which
> contains the last fix of the authentication problem. You can find the *
> UJO_0100_seq001_pat123.kids* file in /tmp/.

Reply all
Reply to author
Forward
0 new messages