Hi Fran
>From a WS-Federation specification point of view, the 1st approach is the way >to go. Imagine your applications are used by several companies (not only >company B but also company C, D, ...) where each companie's IDP creates a SAML >token which contains claims information. Even OASIS standardizes some >attribute names like (email, firstname, lastname, etc) there are company >specific attribute names and potentially different values for the same kind of >meaning. Instead of transforming these claims within each application it makes >perfect sense to transform the claims within IDP 1 (the resource IDP). The >resource IDP will then re-issue a SAML token which represents the claims >information which is understood by the application independently from which >company B, C or D the request is coming from. You'll be able to grow and >integrate new companies and application very quickly. The Mock IDP doesn't support to redirect the request to another IDP yet. Of course, you must first set up a local IDP. If you start with one external company you could consider to redirect directly to their IDP (still WS-Federation compliant) and set up a local IDP (resource IDP) at a later stage. If the SAML token doesn't vary much (no external company specific attribute names and such) you could do this maybe also for a 2nd company. Therefore, I could enhance the federation plugin to provide a callback mechanism and priovide the HttpServletRequest object to figure out where the request is coming from and redirect to the one or other IDP. The scenario I described above is about transforming the claims from one company (B, C, ...) to company A. The subject name is not mapped. Another kind of federation is that the identities (subject names) are mapped. This means that a user must have a identity managed in company A and company B. I don't recommend this in a B2B scenario as the user provisioning process is more complex (per user) and if the employee leaves company B the user still has access to the application of company A. But you see this kind of deployment in bigger companies which have several security domains in place due to history (like reorganizations, aquisitions and such). There is no user provisioning required for the claims transformation approach as only the claims data is transformed and the identity is unchanged (used for auditing purposes only). So in summary, for the 1st approach, the mock IDP doesn't support redirect to another IDP. The 2nd approach is not supported in the federation plugin yet. What do you think? Thanks Oli ------ Oliver Wulff http://owulff.blogspot.com<http://owulff.blogspot.com/> Solution Architect Talend Application Integration Division http://www.talend.com ________________________________ Von: Francisco Serrano [[email protected]] Gesendet: Dienstag, 17. Januar 2012 08:53 Bis: [email protected] Betreff: Re: Several IDP-STS servers / Resolver approach Hi again list, As an attachment (now zipped file) you can find the approach I was asking about. Thanks again in advance. El 17/01/2012, a las 08:41, Francisco Serrano escribió: Hi Oliver. It look like. I'l try zipping the file first. Thanks. El 16/01/2012, a las 19:45, Oliver Wulff escribió: Hi Fran Has the attachment been removed? Maybe zip it before. Thanks ------ Oliver Wulff http://owulff.blogspot.com<http://owulff.blogspot.com/><https://owa.talend.com/owa/UrlBlockedError.aspx> Solution Architect Talend Application Integration Division http://www.talend.com ________________________________ Von: Francisco Serrano [[email protected]] Gesendet: Montag, 16. Januar 2012 17:35 Bis: [email protected] Betreff: Several IDP-STS servers / Resolver approach Hi List! I have two questions I'm sure you can help to figure out: One regarding what would you think it would be the best approach when you need several IDP's (imagine an external one at your customer infrastructure for their internal stuff to access our application and an internal one for application local related users). Somehow the correct IDP (the one responsible for delivering the token) will have to be resolved and the main doubt is about whether this "correct" IDP should be resolved directly from the plugin in the container or it should be always resolved by the internal IDP (some kind of redirect to the correct IDP if this "internal" one cannot answer about the authentication issue requested). The second question would be about the existance of support for this "IDP resolution" feature in the project (CXF) As an attachment I summarize in a draft what could be the approach. Thanks in advance for your time, Kind regards, Fran
