|
|
You're in the
dotnet web services enhancements
group:Stateful web service using WSE
dotnet web services enhancements:
We are currently securing our web services using WSE. The reason for
this is interoperability. We want our customers to be able clients using our services with a reasonable effort. Our progress so far is that we have enabled WS-Security and WS-Secureconversation using our custom policy assertion. This works fine although the learning curve have been pretty steep. We plan to later setup our own STS but so far we are relying on the implicit RSTs to create our SCTs. However, we also have a couple of stateful services requiring state to be persisted on the server side. Redesigning them to being stateless is not an option unfortunately. Which way should be proceed to persist state? We need to consider the following requirements: 1) State information should be on the message level, that is SOAP but not HTTP. 2) The service will trust the Identify information in the SCT to identify the user on the first request. 3) The service is secured using WSE 3.0. Preferrably: 4) The solution should be based on a published standard. 5) We should be able to provide not only a user id, but also it's role for each service (a user may have different roles on differnet services). However we would like to not create a custom SCT since this seems to make interoperability quite complex. So far we have investigated the SessionState property on the SoapContext class but been unable to access the information across several requests. Another problem to handle seems to be that the SCTs and the associated proxies seem to be recycled when the SCTs are renewed.
Hi,
[quoted text, click to view] Pablo Cibraro [MVP] wrote: > 1). I am not sure to understand this point, you don't want to use the > ASP.NET session (Http), is that what you mean ?. Or do you want to carry > some state information in every message ?. We would like to stay transport agnostic. I guess we might end up using the ASP.Net StateManager to manage the states but the problem is really where the session identifier should go. I was hoping for someone to point me to that hard to find WS-Session standard ;) My whole issue boils down to that I can't find a standard that WSE implements for this. Seems ebXML has a session implementation using what they call a ConversationID which they place in the SOAP header, but WSE doesn't seem to implement that. [quoted text, click to view] > 4 & 5 ) You might consider SAML for this, it is a published standar. In Yes, we did consider this as well but were hoping to avoid it.> addition, it can be easily extended through custom attributes. There is an > SAML implementation for WSE here, http://practices.gotdotnet.com/saml Extending a published standard is something we're doing to often anyway. [quoted text, click to view] > The session state is only valid per proxy, and it has the problems that you > mentioned. You could develop a custom session mechanism and use the SCT key > or something like that as key to get the information from that session. Is > that a valid approach for you ?. Yes, this sounds great. But how should we handle the situation where the SCTs TTL expire and is replaced by a new one? It seems we would still need a session identifier that goes above the SCT scope. Or can this be handled somehow? Best regards, JS
[quoted text, click to view]
JS wrote: > I was hoping for someone to > point me to that hard to find WS-Session standard ;) Well, I should have searched of course, ECMA publishes a WS-Session standard which I'm gonna look into now, but it doesn't seem to be implemented in WSE. Brgds, JS
Hi,
1). I am not sure to understand this point, you don't want to use the ASP.NET session (Http), is that what you mean ?. Or do you want to carry some state information in every message ?. 4 & 5 ) You might consider SAML for this, it is a published standar. In addition, it can be easily extended through custom attributes. There is an SAML implementation for WSE here, http://practices.gotdotnet.com/saml The session state is only valid per proxy, and it has the problems that you mentioned. You could develop a custom session mechanism and use the SCT key or something like that as key to get the information from that session. Is that a valid approach for you ?. Regards, Pablo Cibraro http://weblogs.asp.net/cibrax [quoted text, click to view] "JS" <joystud@gmail.com> wrote in message news:1161251956.750480.283060@m7g2000cwm.googlegroups.com... > We are currently securing our web services using WSE. The reason for > this is interoperability. We want our customers to be able clients > using our services with a reasonable effort. > > Our progress so far is that we have enabled WS-Security and > WS-Secureconversation using our custom policy assertion. This works > fine although the learning curve have been pretty steep. > > We plan to later setup our own STS but so far we are relying on the > implicit RSTs to create our SCTs. > > However, we also have a couple of stateful services requiring state to > be persisted on the server side. Redesigning them to being stateless is > not an option unfortunately. Which way should be proceed to persist > state? > > We need to consider the following requirements: > 1) State information should be on the message level, that is SOAP but > not HTTP. > 2) The service will trust the Identify information in the SCT to > identify the user on the first request. > 3) The service is secured using WSE 3.0. > > Preferrably: > 4) The solution should be based on a published standard. > 5) We should be able to provide not only a user id, but also it's role > for each service (a user may have different roles on differnet > services). However we would like to not create a custom SCT since this > seems to make interoperability quite complex. > > So far we have investigated the SessionState property on the > SoapContext class but been unable to access the information across > several requests. Another problem to handle seems to be that the SCTs > and the associated proxies seem to be recycled when the SCTs are > renewed. >
Hi Pablo,
I think you could be on to something here! But how could a service (not the STS) get the basetoken (such as the usernametoken or binarytoken in our case) out of the SCT? We can't seem to find it available to us there. Best regards, JS [quoted text, click to view] Pablo Cibraro [MVP] wrote:
> Hi > > I understand your concern. You can use the identifier of the base token (The > original token used to create the SCT, for instance, a UsernameToken) > instead of using the SCT identifier. The base token will be the same whether > the SCT is renewed or not. Does it make sense ?. > > Regards, > Pablo. > > "JS" <joystud@gmail.com> wrote in message > news:1161269533.128970.12720@k70g2000cwa.googlegroups.com... > > Hi, > > > > Pablo Cibraro [MVP] wrote: > >> 1). I am not sure to understand this point, you don't want to use the > >> ASP.NET session (Http), is that what you mean ?. Or do you want to carry > >> some state information in every message ?. > > > > We would like to stay transport agnostic. I guess we might end up using > > the ASP.Net StateManager to manage the states but the problem is really > > where the session identifier should go. I was hoping for someone to > > point me to that hard to find WS-Session standard ;) My whole issue > > boils down to that I can't find a standard that WSE implements for > > this. Seems ebXML has a session implementation using what they call a > > ConversationID which they place in the SOAP header, but WSE doesn't > > seem to implement that. > > > >> 4 & 5 ) You might consider SAML for this, it is a published standar. In > >> addition, it can be easily extended through custom attributes. There is > >> an > >> SAML implementation for WSE here, http://practices.gotdotnet.com/saml > > Yes, we did consider this as well but were hoping to avoid it. > > Extending a published standard is something we're doing to often > > anyway. > > > >> The session state is only valid per proxy, and it has the problems that > >> you > >> mentioned. You could develop a custom session mechanism and use the SCT > >> key > >> or something like that as key to get the information from that session. > >> Is > >> that a valid approach for you ?. > > > > Yes, this sounds great. But how should we handle the situation where > > the SCTs TTL expire and is replaced by a new one? It seems we would > > still need a session identifier that goes above the SCT scope. Or can > > this be handled somehow? > > > > Best regards, > > > > JS > >
Hi
I understand your concern. You can use the identifier of the base token (The original token used to create the SCT, for instance, a UsernameToken) instead of using the SCT identifier. The base token will be the same whether the SCT is renewed or not. Does it make sense ?. Regards, Pablo. [quoted text, click to view] "JS" <joystud@gmail.com> wrote in message news:1161269533.128970.12720@k70g2000cwa.googlegroups.com... > Hi, > > Pablo Cibraro [MVP] wrote: >> 1). I am not sure to understand this point, you don't want to use the >> ASP.NET session (Http), is that what you mean ?. Or do you want to carry >> some state information in every message ?. > > We would like to stay transport agnostic. I guess we might end up using > the ASP.Net StateManager to manage the states but the problem is really > where the session identifier should go. I was hoping for someone to > point me to that hard to find WS-Session standard ;) My whole issue > boils down to that I can't find a standard that WSE implements for > this. Seems ebXML has a session implementation using what they call a > ConversationID which they place in the SOAP header, but WSE doesn't > seem to implement that. > >> 4 & 5 ) You might consider SAML for this, it is a published standar. In >> addition, it can be easily extended through custom attributes. There is >> an >> SAML implementation for WSE here, http://practices.gotdotnet.com/saml > Yes, we did consider this as well but were hoping to avoid it. > Extending a published standard is something we're doing to often > anyway. > >> The session state is only valid per proxy, and it has the problems that >> you >> mentioned. You could develop a custom session mechanism and use the SCT >> key >> or something like that as key to get the information from that session. >> Is >> that a valid approach for you ?. > > Yes, this sounds great. But how should we handle the situation where > the SCTs TTL expire and is replaced by a new one? It seems we would > still need a session identifier that goes above the SCT scope. Or can > this be handled somehow? > > Best regards, > > JS >
Hi,
[quoted text, click to view] > If you are using WSE, the STS and the Service are the same. Are you using > the SecureConversation feature provided by the WSE assertions ? > If the answer is yes, you can get the base token from the SCT using the > following code: WSE? Check SecureConversation? Check [quoted text, click to view] > Microsoft.Web.Services3.Security.Tokens.SecurityContextToken sct = > (Microsoft.Web.Services3.Security.Tokens.SecurityContextToken)Microsoft.Web.Services3.RequestSoapContext.Current.IdentityToken; > > Microsoft.Web.Services3.Security.Tokens.SecurityToken baseToken = > sct.BaseToken; Thank you for this, will try this out on monday and let you know what happens. I guess to enable clients to connect without using SecureConversation we would just fallback to use their Usernametoken directly. Brgds and have a nice weekend, JS
Hi JS,
If you are using WSE, the STS and the Service are the same. Are you using the SecureConversation feature provided by the WSE assertions ? If the answer is yes, you can get the base token from the SCT using the following code: Microsoft.Web.Services3.Security.Tokens.SecurityContextToken sct = (Microsoft.Web.Services3.Security.Tokens.SecurityContextToken)Microsoft.Web.Services3.RequestSoapContext.Current.IdentityToken; Microsoft.Web.Services3.Security.Tokens.SecurityToken baseToken = sct.BaseToken; Regards, Pablo. [quoted text, click to view] "JS" <joystud@gmail.com> wrote in message news:1161286311.027838.216130@m7g2000cwm.googlegroups.com... > Hi Pablo, > > I think you could be on to something here! But how could a service (not > the STS) get the basetoken (such as the usernametoken or binarytoken in > our case) out of the SCT? We can't seem to find it available to us > there. > > Best regards, > > JS > > Pablo Cibraro [MVP] wrote: >> Hi >> >> I understand your concern. You can use the identifier of the base token >> (The >> original token used to create the SCT, for instance, a UsernameToken) >> instead of using the SCT identifier. The base token will be the same >> whether >> the SCT is renewed or not. Does it make sense ?. >> >> Regards, >> Pablo. >> >> "JS" <joystud@gmail.com> wrote in message >> news:1161269533.128970.12720@k70g2000cwa.googlegroups.com... >> > Hi, >> > >> > Pablo Cibraro [MVP] wrote: >> >> 1). I am not sure to understand this point, you don't want to use the >> >> ASP.NET session (Http), is that what you mean ?. Or do you want to >> >> carry >> >> some state information in every message ?. >> > >> > We would like to stay transport agnostic. I guess we might end up using >> > the ASP.Net StateManager to manage the states but the problem is really >> > where the session identifier should go. I was hoping for someone to >> > point me to that hard to find WS-Session standard ;) My whole issue >> > boils down to that I can't find a standard that WSE implements for >> > this. Seems ebXML has a session implementation using what they call a >> > ConversationID which they place in the SOAP header, but WSE doesn't >> > seem to implement that. >> > >> >> 4 & 5 ) You might consider SAML for this, it is a published standar. >> >> In >> >> addition, it can be easily extended through custom attributes. There >> >> is >> >> an >> >> SAML implementation for WSE here, http://practices.gotdotnet.com/saml >> > Yes, we did consider this as well but were hoping to avoid it. >> > Extending a published standard is something we're doing to often >> > anyway. >> > >> >> The session state is only valid per proxy, and it has the problems >> >> that >> >> you >> >> mentioned. You could develop a custom session mechanism and use the >> >> SCT >> >> key >> >> or something like that as key to get the information from that >> >> session. >> >> Is >> >> that a valid approach for you ?. >> > >> > Yes, this sounds great. But how should we handle the situation where >> > the SCTs TTL expire and is replaced by a new one? It seems we would >> > still need a session identifier that goes above the SCT scope. Or can >> > this be handled somehow? >> > >> > Best regards, >> > >> > JS >> > >
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |