Hi Oliver,
Thanks for your feedback.
I do agree that the 1st approach would mean less effort and more
maintainability because the effort is done only over one implementation.
For better understanding of the answer, please let me write mine in
between you lines:
> 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.
>
Regarding this, Do you mean that the IDP1 should also be able to process the
token coming from the external IDP (not only redirecting the client to the
external IDP) so this token can be "transformed" according to what the
application expects to have as claims information? That should be cool, but I
see an effort here to reimplement the behaviour of the resource IDP for each
application that needs different claim information. i.e: If application 1 needs
information about the "age" for example, and application 2 does not need this
"age" information but needs information about "gender", the resource IDP would
have to evaluate the source of the token request and depending the source
provide a token with different information. Is this correct?
>
>
> 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.
This would be really great.
>
>
>
> 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).
Ok. I think I understand this. Important to take into count. Thanks.
>
>
>
> 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.
Ok. Never mind about the 2nd approach. As you provided some other important
point of view I also agree this is not the way to go.
>
>
>
> What do you think?
>
>
>
> Thanks
Thanks a lot Oliver.
Fran.
>
> Oli
>
>
>
>
>
> ------
>
> Oliver Wulff
>
> http://owulff.blogspot.com<http://owulff.blogspot.com/>
> Solution Architect
> Talend Application Integration Division http://www.talend.com
>
> ________________________________
> Von: Francisco Serrano [francisco.serr...@mimacom.com]
> Gesendet: Dienstag, 17. Januar 2012 08:53
> Bis: users@cxf.apache.org
> 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 [francisco.serr...@mimacom.com]
> Gesendet: Montag, 16. Januar 2012 17:35
> Bis: users@cxf.apache.org
> 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
>
>
>
>
>
>
>
