RE: Creating JMS Dataportal Channels/Routers. A security question.

RE: Creating JMS Dataportal Channels/Routers. A security question.

Old forum URL: forums.lhotka.net/forums/t/988.aspx


RockfordLhotka posted on Wednesday, August 23, 2006

So I understand, what you are doing with JMS is passing messages from a .NET client to a .NET server - but that server is hosted within a process created by JMS? And, of course, JMS doesn't have any mechanism by which it can flow the client Windows credentials through to the server for impersonation, so on the server you actually want to use some type of custom principal that emulates the user's Windows identity?
 
Rocky


From: slabanum [mailto:cslanet@lhotka.net]
Sent: Tuesday, August 22, 2006 5:04 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Creating JMS Dataportal Channels/Routers. A security question.

Rocky,

Sorry, but I have to ask this questions so it becomes clear. 

1) Where is the most likely place for me to call ApplicationContext.ClientContext.Add("ClientPrincipal", Serialize(GetPrincipal()))?  Should it be on the initialization phase (eg. Form Load or main()) of a UI or should it be during the Initialize() phase of my business object (override Core.BusinessBase.Initialize())?

2) When I check for authorization should I check for it on the ClientContext like the example on DataPortal_xyz:

      if not (Ctype( Deserialize(ApplicationContext.ClientContext.Item("ClientPrincipal"), IPrincipal).IsInRole("SomeRole") then

     throw some exception

    end if

The reason I asked is on the server-side, ApplicationContext.User would return the user that is used to start my server-side component, not the client's principal since Server.DataPortal.SetContext does not set the ApplicationContext.User to the client's principal (In the first place Client.DataPortal's GetPrincipal return's nothing on "Windows" authentication).

I guess this is a trade-off for marrying different worlds of technology.

Thanks.




Copyright (c) Marimer LLC