At 11:28 AM -0400 5/11/05, Goertzel Karen wrote:
>Of course, and SSO is only as secure as (1) the assurance of the
>credential on which it bases its authentication decisions (a static
>password with an SSO is a really STUPID idea);
That depends on the security of the channel between the user and
At 11:00 AM -0500 5/11/05, Gizmo wrote:
>Maybe I don't fully understand the concept of Single Sign-On.
>
>As I understand it, SSO allows a user to login to an application portal, and
>all of the applications that user accesses via that portal know who the user
>is and what rights they have within t
After getting served a large helping of humble pie and ruminating on the
texture and taste thereof, Gizmo responded with:
Good points, Dana, and eloquently put. I think you have stated what I was
really driving at, much better than I did. :-) However, if you think that
MS won't find a way to dr
Isn't a Single Sign-on System supposed to address exactly this kind of
problem?
Users need to be authenticated individually. Also, they don't want to
have to deal with multiple sets of credentials and different login
procedures for different apps/systems.
Login requirements for various apps and
I don't think its fair to paint such a broad stroke about Microsoft's intent.
Microsoft is a business. And a business that has to weigh its investments
carefully through its metrics driven organization, just like every other
successful business out there. They enter into markets for three general
Keith Brown has a good discussion of at least one of the design choices, namely
delegation vs. impersonation:
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsDelegation.html
&
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsImpersonation.html
-gp
Quoting Gizmo <[EMA
Neither impersonation nor delegation work for this environment: the DB
itself is encrypted using the owner name as the key. It doesn't matter in
the slightest what user rights you have to the server; if you don't have the
owner name you can't decrypt the data in the DB (at least, not without a LOT
Maybe I don't fully understand the concept of Single Sign-On.
As I understand it, SSO allows a user to login to an application portal, and
all of the applications that user accesses via that portal know who the user
is and what rights they have within their respective application realms. As
such,
I have a similar situation in one of my applications. The customer wishes
to secure the database. Since we use a Btrieve database, the only way to do
this is be setting an owner name on the DB, and then encrypting using the
owner name as the password. However, once the DB is secured, you can't
a
Microsoft is all about making Windows 'more secure' because they see a
potential revenue stream. Note that their approach is NOT "Let's make the
OS more secure so that this crap can't get installed to start with"; rather,
it is "Let's graft more crap onto the system and then sell people a
subscrip
This is a broad question around the current practices and recommendation of
what not to do when it comes to credentials used by applications to gain
access to a resource or data stored elsewhere.
As an example, I have some middleware components that need to gain access
to a data repository that
FYI, there's a new(ish) article by Kenneth Ballard out on IBM's developerWorks
site, on the topic of secure use of OpenSSL. It's actually part 2 in a
series, but there's a pointer there to part 1 also. The abstract follows,
along with the URL to the full article:
Securing the handshake during
12 matches
Mail list logo
