|
Home > Archive > Commerce Server General > February 2004 > Proxy Accounts in CS2002 ---> Impressions?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Proxy Accounts in CS2002 ---> Impressions?
|
|
| Brian Fung 2004-02-20, 2:37 am |
| Hello Everybody,
I'm going to migrate a Site Server 3.0 site to a CS2002 site. I want
to implement proxy accounts to replace the old P&M. Does anybody have
impressions or opinions on implementing it this way?
Brian
| |
| Michael O'Donovan [MSFT] 2004-02-25, 12:35 pm |
| Hi Brian,
Idepends on exactly why you need a proxy account. You can have proxy accounts in CS2002 - look in the CS docs for "proxy accounts", however this wont have the exact same result as the site server technique.
In site server a proxy account was need because users/groups were stored in SQL/LDAP and you can only grant NTFS file permissions to NT/Active Direcory users. Therefore if created a NT/AD impersonation(proxy) account, the SQL/LDAP user could then "run as" the impersonation account.
Below is a high level overview on how the Site Server authentication service and ISAPI filter work in regards to a impersonation account. Compare this to how the Commerce Server ISAPI filter works in conjunction with Active Directory. There is a lot of reading below, but hopefully it helps.
Commerce Server AuthFilter
1.. User requests a restricted page i.e. IIS anonymous access is not allowed on the file requested - at this point usually an end user would get a basic clear text dialog popup.
2.. User doesn't have CS Auth Ticket, the CS ISAPI filter redirects the user a login page (path to this page is setup in the Commerce Server Manager in the "CS Authentication" global resource). This page can be on a dedicated web server that is not the same as the server that holds the requested page. For this the config path must be set to a fully qualified path e.g. http://login.lexisnexis.co.uk/auth/login.asp. The ISAPI filter adds a cookie (called MSCSFirstRequestedURL) during the redirect; it contains the fully qualified URL of the requested page so that the login page knows where to direct the user after a successful login.
3.. The user will enter a username and password into the login page and submit it. Code will need to be created to check the username and password against AD. If the correct credentials have been supplied a CS Auth Ticket should be issued using the AuthManager.SetAuthTicket method, this will issue an authentication session cookie to the user. The encrypted cookie will contain a username, timestamp and time to live (TTL - used for expiration). The user should then be redirected back to original requested page (using the value from the MSCSFirstRequestedURL cookie). Included on the URL to original page MUST be query string (in a specific format) containing the user's username and password. The CS ISAPI filter uses these values to pass to IIS. Example query string is "?&proxyuser=domainname\administrator&proxypwd=password". The username and password can also be sent to the requested page using an HTTP POST rather that a GET. A sample login.asp page is included with all CS sample sites.
4.. The CS ISAPI filter SF_NOTIFY_AUTHENTICATION event fires just before IIS authenticates a user, and it is at this point that the CS ISAPI filter passes the username and password to IIS. This prevents the end user being prompted with a pop-up dialog box asking for credentials. The CS ISAPI filter caches the user's password in memory. On subsequent page requests the CS Auth Ticket is used to get the user's username, and the password is looked up in the cache, if both are present the ISAPI filter can pass them to IIS to prevent the pop-up dialog box asking for credentials. If the CS Auth Ticket is not present, has expired or the user's password is not in the cache, the user is re-directed to the login page (as in step 2). It must be noted that the CS ISAPI filter also removes the query string from the URL so that the user doesn't see his/her credentials on the URL.
5.. There are a couple of techniques that can be used to prevent users that have been load balanced across CS web servers from being delivered the login page asking for credentials because the user has hit a web server that doesn't have his/her password cached.
6.. Use sticky sessions to ensure the user always returns to the same web server
7.. Code the login page to maintain a password cache (this could be in memory, or some other store e.g. SQL). When a user is directed to the login page and the user has a valid CS Auth Ticket, check to see if his/her password is in the cache. If it is redirect the user back to the requested page with the appropriate query string, else display the login page. This will force the ISAPI filter to cache the user's password.
So as you can see, you can create a impersonation account and this accounts details must be passed to the CS ISAPI filter. This account must be an AD account.
Site Server Authentication
There are several differences in the way the Site Server ISAPI filter and Commerce Server 2002 ISAPI filters work. Below is a high level overview of how the Site Server authorization mechanism works in terms of using NTFS permissions to grant/deny access to users.
Users and groups in the Membership Directory cannot be placed directly in Windows ACLs, but they can be mapped to Windows NT/AD groups, which are used in ACLs to protect applications and content. When your site uses Membership Authentication mode, for each group created in the Membership Directory, each Site Server Authentication Service automatically creates on its respective server computer a corresponding Windows group. A Membership Directory group called groupname would be mapped to a Windows group called SiteSrv_directoryname groupname, including any group nesting. Here are two examples:
· A group cn=toys, ou=groups, o=acme would be mapped to the group Site_acme_toys.
· A group cn=toys, ou=manufacturers, ou=groups, o=acme would be mapped to the group Site_acme_manufacturers_toys.
Note
· Local or Domain global groups can be used.
At the most basic level, the user is represented by an account in the Membership Directory. The user is assigned to groups in the Membership Directory that correspond to the content that the user is authorized to access.
This authorization information needs to be made available to the applications to which the client would connect. To accomplish this, P&M automatically creates a special Windows NT Server user account, the Impersonation Account (with the name MemProxyUser_n), for every Membership Server instance that is used for authentication. Every user who is authenticated is logged on to the application server as an instance of its corresponding Impersonation Account.
For each instance of the Impersonation Account, a unique Windows security context is created, which corresponds to the current user's permissions in the Membership Directory. As part of authentication, the Site Server Authentication Service interrogates the Membership Directory to determine all the groups and subgroups the user belongs to. When the Impersonation Account instance is logged on, the corresponding (mapped) Windows user groups are attached to the security context of the Impersonation Account instance, thereby giving the Impersonation Account the effect of the same group memberships as the user has in the Membership Directory. This Site Server Authentication Service communicates to the P&M store on behalf of the ISAPI filter. The security context is created as a standard Windows security token containing the Security IDs (SIDs) of the Impersonation Account and all Windows groups which map to groups that the user belongs to in the Membership Directory. It is this token that the ISAPI filter passes to IIS to enforce the correct security context.
As a result any resources requested through IIS will use the security context of the impersonation account and the associated groups for that session.
The Commerce Server ISAPI filter doesn't work in this way at all. The Commerce Server ISAPI filter uses a Windows username and password passed on a query string to create a security context. Hence all resources request through IIS will use the security context of the username passed on the query string, and its associated group permissions. This user must be a Windows user (local computer account or AD account).
Hope this helps,
Michael
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brian Fung" <bfung25@hotmail.com> wrote in message news:e0d644.0402200754.53ad7a78@posting.google.com...
> Hello Everybody,
>
> I'm going to migrate a Site Server 3.0 site to a CS2002 site. I want
> to implement proxy accounts to replace the old P&M. Does anybody have
> impressions or opinions on implementing it this way?
>
> Brian
| |
| Brian Fung 2004-02-26, 8:35 pm |
| Thanks for the response Micheal. That really helped a lot.
My question to you is how secure is it to user the Response.redirect
and having the UserID and PASWORD in the querystring? Isn't that a
security risk? It not, then why?
Brian
"Michael O'Donovan [MSFT]" <michodon@online.microsoft.com> wrote in message news:<u$vi$T8#DHA.1036@TK2MSFTNGP10.phx.gbl>...
> Hi Brian,
>
> Idepends on exactly why you need a proxy account. You can have proxy
> accounts in CS2002 - look in the CS docs for "proxy accounts", however
> this wont have the exact same result as the site server technique.
>
> In site server a proxy account was need because users/groups were stored
> in SQL/LDAP and you can only grant NTFS file permissions to NT/Active
> Direcory users. Therefore if created a NT/AD impersonation(proxy)
> account, the SQL/LDAP user could then "run as" the impersonation
> account.
>
> Below is a high level overview on how the Site Server authentication
> service and ISAPI filter work in regards to a impersonation account.
> Compare this to how the Commerce Server ISAPI filter works in
> conjunction with Active Directory. There is a lot of reading below, but
> hopefully it helps.
>
> Commerce Server AuthFilter
> 1.. User requests a restricted page i.e. IIS anonymous access is not
> allowed on the file requested - at this point usually an end user would
> get a basic clear text dialog popup.
> 2.. User doesn't have CS Auth Ticket, the CS ISAPI filter redirects
> the user a login page (path to this page is setup in the Commerce Server
> Manager in the "CS Authentication" global resource). This page can be on
> a dedicated web server that is not the same as the server that holds the
> requested page. For this the config path must be set to a fully
> qualified path e.g. http://login.lexisnexis.co.uk/auth/login.asp. The
> ISAPI filter adds a cookie (called MSCSFirstRequestedURL) during the
> redirect; it contains the fully qualified URL of the requested page so
> that the login page knows where to direct the user after a successful
> login.
> 3.. The user will enter a username and password into the login page
> and submit it. Code will need to be created to check the username and
> password against AD. If the correct credentials have been supplied a CS
> Auth Ticket should be issued using the AuthManager.SetAuthTicket method,
> this will issue an authentication session cookie to the user. The
> encrypted cookie will contain a username, timestamp and time to live
> (TTL - used for expiration). The user should then be redirected back to
> original requested page (using the value from the MSCSFirstRequestedURL
> cookie). Included on the URL to original page MUST be query string (in a
> specific format) containing the user's username and password. The CS
> ISAPI filter uses these values to pass to IIS. Example query string is
> "?&proxyuser=domainname\administrator&proxypwd=password". The
> username and password can also be sent to the requested page using an
> HTTP POST rather that a GET. A sample login.asp page is included with
> all CS sample sites.
> 4.. The CS ISAPI filter SF NOTIFY AUTHENTICATION event fires just
> before IIS authenticates a user, and it is at this point that the CS
> ISAPI filter passes the username and password to IIS. This prevents the
> end user being prompted with a pop-up dialog box asking for credentials.
> The CS ISAPI filter caches the user's password in memory. On subsequent
> page requests the CS Auth Ticket is used to get the user's username, and
> the password is looked up in the cache, if both are present the ISAPI
> filter can pass them to IIS to prevent the pop-up dialog box asking for
> credentials. If the CS Auth Ticket is not present, has expired or the
> user's password is not in the cache, the user is re-directed to the
> login page (as in step 2). It must be noted that the CS ISAPI filter
> also removes the query string from the URL so that the user doesn't see
> his/her credentials on the URL.
> 5.. There are a couple of techniques that can be used to prevent users
> that have been load balanced across CS web servers from being delivered
> the login page asking for credentials because the user has hit a web
> server that doesn't have his/her password cached.
> 6.. Use sticky sessions to ensure the user always returns to the same
> web server
> 7.. Code the login page to maintain a password cache (this could be in
> memory, or some other store e.g. SQL). When a user is directed to the
> login page and the user has a valid CS Auth Ticket, check to see if
> his/her password is in the cache. If it is redirect the user back to the
> requested page with the appropriate query string, else display the login
> page. This will force the ISAPI filter to cache the user's password.
> So as you can see, you can create a impersonation account and this
> accounts details must be passed to the CS ISAPI filter. This account
> must be an AD account.
>
> Site Server Authentication
>
> There are several differences in the way the Site Server ISAPI filter
> and Commerce Server 2002 ISAPI filters work. Below is a high level
> overview of how the Site Server authorization mechanism works in terms
> of using NTFS permissions to grant/deny access to users.
>
> Users and groups in the Membership Directory cannot be placed directly
> in Windows ACLs, but they can be mapped to Windows NT/AD groups, which
> are used in ACLs to protect applications and content. When your site
> uses Membership Authentication mode, for each group created in the
> Membership Directory, each Site Server Authentication Service
> automatically creates on its respective server computer a corresponding
> Windows group. A Membership Directory group called groupname would be
> mapped to a Windows group called SiteSrv directoryname groupname,
> including any group nesting. Here are two examples:
>
> A group cn=toys, ou=groups, o=acme would be mapped to
> the group Site acme toys.
>
> A group cn=toys, ou=manufacturers, ou=groups, o=acme
> would be mapped to the group Site acme manufacturers toys.
>
>
>
> Note
>
> Local or Domain global groups can be used.
>
> At the most basic level, the user is represented by an account in the
> Membership Directory. The user is assigned to groups in the Membership
> Directory that correspond to the content that the user is authorized to
> access.
>
> This authorization information needs to be made available to the
> applications to which the client would connect. To accomplish this, P&M
> automatically creates a special Windows NT Server user account, the
> Impersonation Account (with the name MemProxyUser n), for every
> Membership Server instance that is used for authentication. Every user
> who is authenticated is logged on to the application server as an
> instance of its corresponding Impersonation Account.
>
> For each instance of the Impersonation Account, a unique Windows
> security context is created, which corresponds to the current user's
> permissions in the Membership Directory. As part of authentication, the
> Site Server Authentication Service interrogates the Membership Directory
> to determine all the groups and subgroups the user belongs to. When the
> Impersonation Account instance is logged on, the corresponding (mapped)
> Windows user groups are attached to the security context of the
> Impersonation Account instance, thereby giving the Impersonation Account
> the effect of the same group memberships as the user has in the
> Membership Directory. This Site Server Authentication Service
> communicates to the P&M store on behalf of the ISAPI filter. The
> security context is created as a standard Windows security token
> containing the Security IDs (SIDs) of the Impersonation Account and all
> Windows groups which map to groups that the user belongs to in the
> Membership Directory. It is this token that the ISAPI filter passes to
> IIS to enforce the correct security context.
>
> As a result any resources requested through IIS will use the security
> context of the impersonation account and the associated groups for that
> session.
>
> The Commerce Server ISAPI filter doesn't work in this way at all. The
> Commerce Server ISAPI filter uses a Windows username and password passed
> on a query string to create a security context. Hence all resources
> request through IIS will use the security context of the username passed
> on the query string, and its associated group permissions. This user
> must be a Windows user (local computer account or AD account).
>
>
> Hope this helps,
> Michael
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Brian Fung" <bfung25@hotmail.com> wrote in message
> news:e0d644.0402200754.53ad7a78@posting.google.com...
> --
| |
| Michael O'Donovan [MSFT] 2004-02-27, 3:34 am |
| Hi Brian,
I would assume that you would run SSL across an authenticated session and
hence this would be the same as a user typing in a username and password in
a login page. Also you don't have to put it on the query string you can do a
form post. Check the CS docs for more information.
Hope this helps,
Michael
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Brian Fung" <bfung25@hotmail.com> wrote in message
news:e0d644.0402261711.74e54210@posting.google.com...
> Thanks for the response Micheal. That really helped a lot.
> My question to you is how secure is it to user the Response.redirect
> and having the UserID and PASWORD in the querystring? Isn't that a
> security risk? It not, then why?
>
> Brian
>
>
> "Michael O'Donovan [MSFT]" <michodon@online.microsoft.com> wrote in
message news:<u$vi$T8#DHA.1036@TK2MSFTNGP10.phx.gbl>...[color=darkred]
[color=darkred]
|
|
|
|
|