" 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. > >
