WARNING
Most of this topic should be considered obsolete, and I would advise people to ignore the draft document below because it is no longer reflective of my current thinking on the topic, let alone any kind of serious proposal that would be implemented as part of Shibboleth. That doesn't mean something won't get done, but I believe we need an open solution to achieve the necessary buy-in and leverage, and these profiles, to say nothing of research projects that hack on top of the existing code base to make it "sort of SOAP-based", are not the way to go.
I think we will have a lot of useful specs to work from once SAML 2.0 support is done, and if people are seriously interested in these problems, the best way to help is to work jointly on an open solution with a good foundation.
I will try and begin to replace this content soon with some material I think is more in line with where the project should go.
-- Main.ScottCantor - 3 Mar 2006
Initial draft of a set of new profiles building on SAML 2.0 to support delegation:
http://shibboleth.internet2.edu/docs/draft-cantor-saml-sso-delegation-01.pdf
Feel free to add comments here...
I discussed this with one of our uPortal experts, asking two main questions. I've edited the email discussion to make a more coherent document, so any mistakes are mine.
Q1. Does this make sense from the portal point of view?
A: It isn't completely clear where the attributes at the second service provider (SPb) come from - are they obtained directly from the Identity Provider or from the delegating service provider (SPa)? (The two of us read the profile and understood it to mean different things here.) Whichever is meant, there would clearly have to be agreements between the portal/SPa and SPb, and between the !IdP and each of SPa and SPb, and there would have to be some non-empty intersection between the expected attribute names; I think in general, all three would be part of a single trust federation. (The issue discussed here was basically how does SPb know what attribute names to use to get information about the user.)
Scott: Attributes are essentially out of scope in some respects. Delegation assertions can contain attributes, encrypted or otherwise, which means they could be forwarded to SPb by SPa. Or, an encrypted NameID shared between the !IdP and SPb can be supplied that enables SPb to query the !IdP for them after the fact. There are many ways to do it. There is no requirement that SPa and SPb share a NameID for the user or have any direct knowledge of the attributes the other one requires.
Federations are mostly out of scope, how you validate assertions is never covered in these kinds of profiles. The !IdP has to be trusted in some fashion by both SPs, but I don't think there's any requirement for SPb to trust SPa or even know about it in advance. The key proof used by SPa is based on the trust placed by SPb in the !IdP.
As for the last question, I think that's a case of not understanding how attribute exchange works. There's nothing special about this use case vs. any other SAML SP from that point of view. Of course you have to know what information you can get and whether you got it.
Simon: Attributes may be out of scope of the profile itself, but the people likely to use this profile as the basis for their work, it seems to me, are likely to be experts in the technology wanting to perform the delegation rather than Shibboleth - they'll know uPortal, for example, rather than the Shibboleth architecture. I'd say that this means that the profile should be accompanied by some documentation aimed specifically at these people, who will need to know things like having to get SPb and the Unable to render embedded object: File (IdP to agree on attribute names without wanting to go into great details in the Shibboleth architecture. I'd agree that there's no difference to other cases here technically, but I feel that questions of this sort are likely to come up because of the type of user of this profile. Your answer helped clarify things to our developer better than my answer did) not found.
Q2. How much effort would be required to adapt existing portlets or write new portlets to use this profile?
A: The following would be required:
1. Portlet should be configured to request necessary info from the Portal (assuming that SPb obtains attributes from SPa).
I am assuming this would be through the user-attributes mechanism.
Scott: By portlet, I guess this means the bit of code that runs inside the portal and acts as a proxy to the remote web service. Attributes are immaterial to this. If the portlet wants to authenticate as the user to the web service, this profile provides a means to do that, if the portlet has access to SPa's key. The portlet is the SP, essentially. How it gets the token is not really part of the profile. In a Shibboleth SP, the exportAssertion option could potentially be used to push it into the environment, or other APIs could be supplied in Java perhaps. Maybe that's the mechanism you mean.
2. The portlet would need to construct the necessary
<wsse:Security>
SOAP header block (see the example on page 22).
This code could be reused by any cantor-saml-sso-delegation SOAP client so I'd expect to see it in a library eventually.
3. The portlet would need to add this header block to its SOAP requests.
Scott: The profile to attach the token is fairly separate, I just provided a straw man example, and I don't really think it's my place to do it. It's a standard assertion, and WSS provides a million ways of attaching it. That's kind of the problem, there are too many ways.
Simon: This again suggests to me that accompanying documentation should help developers make decisions about which way to use here.
4. The portlet would need to handle any SOAP faults returned as a consequence of failed authorisation.
Scott: Definitely an application issue, this shouldn't be anything new.
5. If modifiying an existing portlet, there may need to be changes to existing code relating to existing authorisation methods.
Scott: One of the basic questions in my mind comes down to demand. I believe that if there are "existing" methods in use and working for people, getting them to buy off on even this level of complexity (to say nothing of full WS-* stuff) will be very hard. This is one of those things where I think this either has to solve a problem that just doesn't have any other obvious solutions or it's going to go nowhere.
Simon: Obviously, there are certainly reasons why you might want to do this for existing services - for example wanting to have anonymity of the end user at SPb, or improving interoperability of the portlet so it can be re-used without modification to fit local authentication regimes, or even SPb turning off existing authorisation methods in favour of Shib. But you're probably right in that new portlets are going to be the main ways in which this profile will get used.
The following are outside the scope of your question (i.e. not the portlet) but relevant anyway:
A. The Portal would need to be able to provide the information requested by the Portlet (in step 1 above)
Scott: I suppose each portlet could in theory be defined in metadata with their own keys, and the portal SP can request delegation authority for those portlets so that the token used for SSO to the portal SP can then get pushed into the portlets and they can forward it to their services if needed.
B. The portlet's target service would have to be cantor-saml-sso enabled.
Scott: I think the hope would be that whatever is done is WS-I BSP compliant and is not at all a departure from standard WSS processing. But in WSS, anything you do with the token afterward is out of scope, so it's the token processing by the application that is a new piece of work, but that could be wrapped pretty easily and the web service can just access the filtered attributes much like a regular webapp would.
-- Main.SimonMcLeish - 08 Nov 2005