Pablo,
I think we are in violent agreement on the first point. Let me state what I think we are both saying. The profile id should be removed from the public interface (the WSDL) for the web services and instead be retrieved from the claims. Non-public interfaces and the BSL should still have the profile id as a parameter. My response about the login/logout functionality was less about the mechanics and more a question of whether the group sees a need for the functionality to remain. I tend to close my browser to clear up everything when I am testing so I don't use the logout functionality. Others might have a different method for testing and would like to be able to logout instead of closing browser windows. Scott > From: [email protected] > To: [email protected] > Date: Fri, 2 Oct 2009 08:02:31 -0700 > Subject: RE: Profile ID claim > > " My intent in the specification document was that the profile id would be > passed as a claim and that the web service could extract the profile id from > the claim. The underlying methods could still have profile id as a parameter > to reduce the code churn." > > - Yes, I know that removing the profile id parameter from the operation > represents some work, but I think I will produce a more cleaner interface. > Otherwise, it's quite confusing for someone looking for first the time the > application or someone that only wants to consume the services and does not > know anything about the internal implementation. The main question would be > "why I should send the profile id as argument, if the same info is also > available as a claim in the SAML token" > > "When I first showed the passive STS I had some feedback that it "would be > nice" to still be able to login/logout so I could test multiple users or > change the configuration and reset the services without having to close all > open browser windows. If that is still a valid request then I think we should > look into how to enable the functionality. I expect that the login page > itself will go away and most likely the code associated with it but that > clicking on the login/logout UI would have the expected behavior. If this is > no longer a request then by all means lets clean up the code by removing the > login/logout UI and associated code." > > - Regarding the login/logout methods. It's fine to have that functionality as > part of the UI, so the user can login/logout in the application, which is > equivalent to login into the Passive STS. However, I am talking here about > the login/logout operations in the Business Service Contract. The login > operation in this context would be equivalent to login into the Active STS > for getting a SAML token with the profile id (and not sure if we could > include the rest of the data returned by the login method as claims in that > token). We don't really need the logout operation at all if we negotiate the > token with the active STS for every service call, or we cache that token > somewhere and we kill it when the user logout in the web application. > > > -----Original Message----- > From: Scott Golightly [mailto:[email protected]] > Sent: Friday, October 02, 2009 11:38 AM > To: Stonehenge Development > Subject: RE: Profile ID claim > > > +1 on the profile id as a claim > > > > My intent in the specification document was that the profile id would be > passed as a claim and that the web service could extract the profile id from > the claim. The underlying methods could still have profile id as a parameter > to reduce the code churn. > > > > +0 on removing the login/logout > > > > When I first showed the passive STS I had some feedback that it "would be > nice" to still be able to login/logout so I could test multiple users or > change the configuration and reset the services without having to close all > open browser windows. If that is still a valid request then I think we should > look into how to enable the functionality. I expect that the login page > itself will go away and most likely the code associated with it but that > clicking on the login/logout UI would have the expected behavior. If this is > no longer a request then by all means lets clean up the code by removing the > login/logout UI and associated code. > > I did create GetProfileIdFromStsIdentifier method to return the profile id > based on the issuing STS and the unique identifier provided by that STS. > > > > Scott Golightly > > > From: [email protected] > > To: [email protected] > > Date: Thu, 1 Oct 2009 17:36:02 -0400 > > Subject: RE: Profile ID claim > > > > +1 > > > > -Ben Dewey > > > > -----Original Message----- > > Date: Thursday, October 01, 2009 5:32:55 pm > > To: [email protected] > > From: "Pablo Cibraro" <[email protected]> > > Subject: Profile ID claim > > > > Hi, > > > > I've been looking into the metro implementation source code, and it looks > > like you still have the user profile id as an argument in almost all the > > request messages. I am currently implementing some changes in the .NET > > implementation, so I think it would be a good idea to pass that attribute > > as a claim that can be gotten from the Active STS. > > > > If we all agree on this, I think we could use a claim like this to > > represent the profile id. > > > > Claim name: "http://trade.com/profile_id"; > > Claim value: an string representing the user profile id > > > > There are some methods in the Business Service that don't make sense > > anymore like Login or Logout. The login method is still useful for getting > > some data about the user profile, so I think we rename it somehow to > > something meaningful. > > > > Let me know what you all think about this, so I can update the current > > specification with these changes. > > > > Thanks > > Pablo. > > > > > >
