|
|
|
date: Fri, 18 Jul 2008 02:46:01 -0700,
group: microsoft.public.dotnet.security
back
SSO in a hosted solution
(I am not sure I am posting this to the right group - if not, please advise
on a better group to use...)
I am looking for a way to allow end-users to use Single Sign-on to log in to
a hosted web-based application, i.e. using their normal windows UID/PWD - or
just having the normal transparent auto-authentication going on.
Background:
We provide a web-based employee self-service module as part of our offerings
to clients. When they install our systems locally, it is fairly easy to
provide SSO: We just deny anonymous access to the login page which causes IIS
to authenticate the user against AD and we get a SID. Depending on the user's
settings, this will either happen automatically or the browser will prompt
him/her to re-enter their UID/PWD.
We do also offer a hybrid solution where all of the above takes place, but
we still get them to type their PWD into a form to re-authenticate and then
we check that against AD - but we can leave that out of this discussion for
simplicity.
Now, we also provide this software in a hosted environment where we
obviously haven't got access to the client's AD so can't do any of the above.
Our client's would - obviously - like SSO on the hosted system, but there
doesn't seem to be a simple way of doing it.
We could potentially set up a VPN and/or some trust, but it seems like a lot
of work. Or we could get a copy of all their UIDs and PWDs but I don't think
they would be keen to give us their passwords... Part of the "problem" with a
hosted system is that the whole message to the client is that their IT Team
doesn't have to get involved, so whatever solution we come up with has to be
quite transparent.
I am thinking that maybe the solution is something like this;
1) Create our own authentication method in IIS which will allow users to
have the same experience - i.e. invisible login. This would probably mean
exposing something like the same challenge/response as is used, rather than
using clear-text. I am not even sure if that is possible, though.
2) Get the clients to agree to give us a list of all UID/PWDs but with the
passwords hashed (one-way, lossy so there is no way of decrypting). We'd
create a little program on their side which would push this list to a
webservice on the hosted system every so often.
3) Somehow get our own login method to look like a normal challenge/response
but then compare against the hastable.
Truth is, I am not that well versed on IIS authentication methods yet so I
am really looking for pointers.
Some of the things I am looking to explore includes cardspace, OpenID etc -
but I think they all require individuals to sign up.
There is SAML, which Google are using, but I don't think AD supports that
readily.
ADAM or some similar AD replication may also work?
In any case, I think this is a fairly generic problem that most providers of
hosted software must come across and I'd be interested to get any pointers to
standard solutions. Much better if I don't have to build it myself :)
Thanks,
Frans
date: Fri, 18 Jul 2008 02:46:01 -0700
author: Frans am
Re: SSO in a hosted solution
AD supports SAML through WS-Federation and their ADFS product. It is the
easiest and cleanest way to set up something like this for a hosted
solution, although it requires you and your client to deploy ADFS.
ADFS is pretty easy to integrate into an application that is already
IIS-based, although it is easiest if the web app is .NET version 2.0 or
higher. ADFS as a server is neither difficult nor particularly expensive to
deploy since it comes with a Windows Server 2003 R2 enterprise license (or
2008) and doesn't cost extra.
This is what we insist on using for use cases like this because most of the
other solutions are not appealing. For example, if you were to implement
some type of LDAP auth solution in your hosted environment, you would need
to drill a hole in my firewall to hit my LDAP server (AD or ADAM; doesn't
really matter here) which I don't want to do AND my users are providing you
with their plaintext AD credentials which I REALLY don't want them to do.
If you don't want to use WS-Federation and want to support the SAML protocol
instead, there are also options for doing that. You can't use ADFS then (it
only supports WS-Fed), but there are a variety of other products and
solutions out there that support SAML 1.1, 2.0, WS-Fed or even all three and
also integrate with AD.
From my perspective, the "right" thing to do as a vendor offering a hosted
solution that benefits from SSO is to choose an option that goes down the
standards-based direction for federated SSO; SAML and/or WS-Fed. If you
want to attract the most potential clients to this, pick a solution that
offers both. That way, the MS/ADFS shops can use WS-Fed and the other shops
can use whatever system they have for providing SAML support. Staying away
from proprietary solutions or approaches that require firewall holes and
collection of plaintext credentials is better strategically.
Best of luck with whatever you opt to do.
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Frans" <flytzen@newsgroup.nospam> wrote in message
news:9B27DD49-B02E-4152-89C1-E125EB36DCC2@microsoft.com...
> (I am not sure I am posting this to the right group - if not, please
> advise
> on a better group to use...)
>
> I am looking for a way to allow end-users to use Single Sign-on to log in
> to
> a hosted web-based application, i.e. using their normal windows UID/PWD -
> or
> just having the normal transparent auto-authentication going on.
>
> Background:
> We provide a web-based employee self-service module as part of our
> offerings
> to clients. When they install our systems locally, it is fairly easy to
> provide SSO: We just deny anonymous access to the login page which causes
> IIS
> to authenticate the user against AD and we get a SID. Depending on the
> user's
> settings, this will either happen automatically or the browser will prompt
> him/her to re-enter their UID/PWD.
> We do also offer a hybrid solution where all of the above takes place, but
> we still get them to type their PWD into a form to re-authenticate and
> then
> we check that against AD - but we can leave that out of this discussion
> for
> simplicity.
>
> Now, we also provide this software in a hosted environment where we
> obviously haven't got access to the client's AD so can't do any of the
> above.
> Our client's would - obviously - like SSO on the hosted system, but there
> doesn't seem to be a simple way of doing it.
> We could potentially set up a VPN and/or some trust, but it seems like a
> lot
> of work. Or we could get a copy of all their UIDs and PWDs but I don't
> think
> they would be keen to give us their passwords... Part of the "problem"
> with a
> hosted system is that the whole message to the client is that their IT
> Team
> doesn't have to get involved, so whatever solution we come up with has to
> be
> quite transparent.
>
> I am thinking that maybe the solution is something like this;
> 1) Create our own authentication method in IIS which will allow users to
> have the same experience - i.e. invisible login. This would probably mean
> exposing something like the same challenge/response as is used, rather
> than
> using clear-text. I am not even sure if that is possible, though.
>
> 2) Get the clients to agree to give us a list of all UID/PWDs but with the
> passwords hashed (one-way, lossy so there is no way of decrypting). We'd
> create a little program on their side which would push this list to a
> webservice on the hosted system every so often.
>
> 3) Somehow get our own login method to look like a normal
> challenge/response
> but then compare against the hastable.
>
>
> Truth is, I am not that well versed on IIS authentication methods yet so I
> am really looking for pointers.
> Some of the things I am looking to explore includes cardspace, OpenID
> etc -
> but I think they all require individuals to sign up.
> There is SAML, which Google are using, but I don't think AD supports that
> readily.
> ADAM or some similar AD replication may also work?
>
> In any case, I think this is a fairly generic problem that most providers
> of
> hosted software must come across and I'd be interested to get any pointers
> to
> standard solutions. Much better if I don't have to build it myself :)
>
>
> Thanks,
> Frans
date: Fri, 18 Jul 2008 09:43:33 -0500
author: Joe Kaplan
Re: SSO in a hosted solution
Thanks Joe,
I think this is exactly what I need!
Frans
"Joe Kaplan" wrote:
> AD supports SAML through WS-Federation and their ADFS product. It is the
> easiest and cleanest way to set up something like this for a hosted
> solution, although it requires you and your client to deploy ADFS.
>
> ADFS is pretty easy to integrate into an application that is already
> IIS-based, although it is easiest if the web app is .NET version 2.0 or
> higher. ADFS as a server is neither difficult nor particularly expensive to
> deploy since it comes with a Windows Server 2003 R2 enterprise license (or
> 2008) and doesn't cost extra.
>
> This is what we insist on using for use cases like this because most of the
> other solutions are not appealing. For example, if you were to implement
> some type of LDAP auth solution in your hosted environment, you would need
> to drill a hole in my firewall to hit my LDAP server (AD or ADAM; doesn't
> really matter here) which I don't want to do AND my users are providing you
> with their plaintext AD credentials which I REALLY don't want them to do.
>
> If you don't want to use WS-Federation and want to support the SAML protocol
> instead, there are also options for doing that. You can't use ADFS then (it
> only supports WS-Fed), but there are a variety of other products and
> solutions out there that support SAML 1.1, 2.0, WS-Fed or even all three and
> also integrate with AD.
>
> From my perspective, the "right" thing to do as a vendor offering a hosted
> solution that benefits from SSO is to choose an option that goes down the
> standards-based direction for federated SSO; SAML and/or WS-Fed. If you
> want to attract the most potential clients to this, pick a solution that
> offers both. That way, the MS/ADFS shops can use WS-Fed and the other shops
> can use whatever system they have for providing SAML support. Staying away
> from proprietary solutions or approaches that require firewall holes and
> collection of plaintext credentials is better strategically.
>
> Best of luck with whatever you opt to do.
>
> Joe K.
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> --
> "Frans" <flytzen@newsgroup.nospam> wrote in message
> news:9B27DD49-B02E-4152-89C1-E125EB36DCC2@microsoft.com...
> > (I am not sure I am posting this to the right group - if not, please
> > advise
> > on a better group to use...)
> >
> > I am looking for a way to allow end-users to use Single Sign-on to log in
> > to
> > a hosted web-based application, i.e. using their normal windows UID/PWD -
> > or
> > just having the normal transparent auto-authentication going on.
> >
> > Background:
> > We provide a web-based employee self-service module as part of our
> > offerings
> > to clients. When they install our systems locally, it is fairly easy to
> > provide SSO: We just deny anonymous access to the login page which causes
> > IIS
> > to authenticate the user against AD and we get a SID. Depending on the
> > user's
> > settings, this will either happen automatically or the browser will prompt
> > him/her to re-enter their UID/PWD.
> > We do also offer a hybrid solution where all of the above takes place, but
> > we still get them to type their PWD into a form to re-authenticate and
> > then
> > we check that against AD - but we can leave that out of this discussion
> > for
> > simplicity.
> >
> > Now, we also provide this software in a hosted environment where we
> > obviously haven't got access to the client's AD so can't do any of the
> > above.
> > Our client's would - obviously - like SSO on the hosted system, but there
> > doesn't seem to be a simple way of doing it.
> > We could potentially set up a VPN and/or some trust, but it seems like a
> > lot
> > of work. Or we could get a copy of all their UIDs and PWDs but I don't
> > think
> > they would be keen to give us their passwords... Part of the "problem"
> > with a
> > hosted system is that the whole message to the client is that their IT
> > Team
> > doesn't have to get involved, so whatever solution we come up with has to
> > be
> > quite transparent.
> >
> > I am thinking that maybe the solution is something like this;
> > 1) Create our own authentication method in IIS which will allow users to
> > have the same experience - i.e. invisible login. This would probably mean
> > exposing something like the same challenge/response as is used, rather
> > than
> > using clear-text. I am not even sure if that is possible, though.
> >
> > 2) Get the clients to agree to give us a list of all UID/PWDs but with the
> > passwords hashed (one-way, lossy so there is no way of decrypting). We'd
> > create a little program on their side which would push this list to a
> > webservice on the hosted system every so often.
> >
> > 3) Somehow get our own login method to look like a normal
> > challenge/response
> > but then compare against the hastable.
> >
> >
> > Truth is, I am not that well versed on IIS authentication methods yet so I
> > am really looking for pointers.
> > Some of the things I am looking to explore includes cardspace, OpenID
> > etc -
> > but I think they all require individuals to sign up.
> > There is SAML, which Google are using, but I don't think AD supports that
> > readily.
> > ADAM or some similar AD replication may also work?
> >
> > In any case, I think this is a fairly generic problem that most providers
> > of
> > hosted software must come across and I'd be interested to get any pointers
> > to
> > standard solutions. Much better if I don't have to build it myself :)
> >
> >
> > Thanks,
> > Frans
>
>
>
date: Fri, 18 Jul 2008 08:00:01 -0700
author: Frans am
|
|
