"If anybody reverse engineers the dll and identifies how you're retrieving/building the login credentials, they can then log in as anybody..."
What if you revalidate the credentials in the area plugin? Axton On Wed, Dec 3, 2008 at 10:01 AM, Jason <[EMAIL PROTECTED]> wrote: > ** > The white paper is just about useless. It provides the base code for a dll > that the v7+ user tool will check for when it's opening. The dll base code > supplies a static username, password, and preference server/port/rpc. If > you're not a programmer, you'll need to hire one to build an application > that the dll can call, collect or generate login credentials, and then > supply that information to the user tool. (BMC will not provide any support > for this. All they will give you is the base code that will let your > programmer know what values to provide for authentication.) The major > problem with the dll is that it still requires a username and password. Your > external application will need to pull or build that information then supply > it to the system. If you're using the mid-tier too, you'll need to build a > solution that works to retrieve login credentials from both clients. The > downside to the dll is security. There's no way to force the use of the dll. > It's simply a file that resides on the client machine. If you delete it, > you'll get the regular login prompt. If anybody reverse engineers the dll > and identifies how you're retrieving/building the login credentials, they > can then log in as anybody. Anybody accept admins. Admins will still need to > login manually. The dll doesn't work for the Admin tool. The dll doesn't > work well with the alert tool either. It'll login, but in the 7.0 > version(haven't tried with 7.1) it would prompt you for a username when > trying to open any alerts unless an instance of the usertool is already > running. > > There is a working group comprised of BMC and DOD Remedy Developers, etc... > that are working on a solution. However, I haven't heard from them in quite > some time so I wouldn't hold your breath. > > > Jason Bess > Bess Development Corp > > ________________________________ > From: "Kaiser, Norm E CIV USAF AFMC 96 CS/SCCE" <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, December 3, 2008 5:35:52 PM > Subject: Re: SSO & CAC Authentication > > It's not too hard doing it on the Midtier, but doing it on the client is > much more involved. Like Jennifer Meyer said, to do it on the client, > there's a whitepaper out there somewhere. > > Good luck! I don't know anyone who's done it successfully... > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Abdullah Baytops > Sent: Tuesday, December 02, 2008 11:35 AM > To: [email protected] > Subject: SSO & CAC Authentication > > ** > Hello Listers > > Does anyone have any information on how to begin with an CAC auth. for a > government client? We have a requirement to have users have the ability > to login using SSO & CAC cards. Has anyone done this yet or is there a > product to make this a seamless intergration any information would be > appreciated. > > V/R > Abdul Baytops > Web: www.thedigitalcorp.com <http://www.thedigitalcorp.com> > Email: [EMAIL PROTECTED] > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
