You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Francisco Serrano <fr...@mimacom.com> on 2012/01/16 17:35:31 UTC
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
AW: Several IDP-STS servers / Resolver approach
Posted by Oliver Wulff <ow...@talend.com>.
I see another use case to resolve the IDP within the relying party. You could have a different URI of your IDP dependent on whether you want to challenge the browser based on kerberos or username token. The reason for that is if you initially tried to challenge the browser with kerberos (spnego), you can't fallback to username/password - or it depends at least on the browser version (processing html body if http error 401 returned). You could also do this using the wauth parameter in the redirect but this parameter might not be supported by all IDP solutions.
Thanks
------
Oliver Wulff
http://owulff.blogspot.com
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________________
Von: Oliver Wulff [owulff@talend.com]
Gesendet: Mittwoch, 18. Januar 2012 13:56
Bis: users@cxf.apache.org
Betreff: AW: Several IDP-STS servers / Resolver approach
Hi Fran
>>>
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?
>>>
Yes, the IDP 1 must trust the external IDP and transform the token to the naming conventions used within your company. The assumption is that the naming conventions don't differ between the applications hosted by you. Thus, the claims transformation should be required only once per external idp (B2B partner).
The WS-FederationMetadata document describes what kind of claims are required for the application (relying party). As the identity is managed by the external company, they must provide the age and/or gender in their samle token. As far as I remember, the OASIS metadata standard defines a URI for gender and age.
Thanks
------
Oliver Wulff
http://owulff.blogspot.com
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________________
Von: Francisco Serrano [francisco.serrano@mimacom.com]
Gesendet: Mittwoch, 18. Januar 2012 10:22
Bis: users@cxf.apache.org
Betreff: Re: Several IDP-STS servers / Resolver approach
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.serrano@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.serrano@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
>
>
>
>
>
>
>
AW: Several IDP-STS servers / Resolver approach
Posted by Oliver Wulff <ow...@talend.com>.
Hi Fran
>>>
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?
>>>
Yes, the IDP 1 must trust the external IDP and transform the token to the naming conventions used within your company. The assumption is that the naming conventions don't differ between the applications hosted by you. Thus, the claims transformation should be required only once per external idp (B2B partner).
The WS-FederationMetadata document describes what kind of claims are required for the application (relying party). As the identity is managed by the external company, they must provide the age and/or gender in their samle token. As far as I remember, the OASIS metadata standard defines a URI for gender and age.
Thanks
------
Oliver Wulff
http://owulff.blogspot.com
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________________
Von: Francisco Serrano [francisco.serrano@mimacom.com]
Gesendet: Mittwoch, 18. Januar 2012 10:22
Bis: users@cxf.apache.org
Betreff: Re: Several IDP-STS servers / Resolver approach
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.serrano@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.serrano@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
>
>
>
>
>
>
>
Re: Several IDP-STS servers / Resolver approach
Posted by Francisco Serrano <fr...@mimacom.com>.
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.serrano@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.serrano@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
>
>
>
>
>
>
>
AW: Several IDP-STS servers / Resolver approach
Posted by Oliver Wulff <ow...@talend.com>.
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 [francisco.serrano@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.serrano@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
Re: Several IDP-STS servers / Resolver approach
Posted by Francisco Serrano <fr...@mimacom.com>.
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/>
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________
Von: Francisco Serrano [francisco.serrano@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
Re: Several IDP-STS servers / Resolver approach
Posted by Francisco Serrano <fr...@mimacom.com>.
Hi Oliver.
It look like. I'l try zipping the file first. Thanks.
Fran Serrano Pons
Senior Developer – mimacom ibérica
__________________________________________________________________
mimacom Ibérica s.l. |
Avda. Cortes Valencianas, 39 | 46015 Valencia | España
Tel: +34 96.119.96.19
www.mimacom.es<http://www.mimacom.es> | blog.mimacomiberica.es<http://blog.mimacomiberica.es>
__________________________________________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this infor-
mation by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the
sender and delete the material from any computer.
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/>
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________
Von: Francisco Serrano [francisco.serrano@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
AW: Several IDP-STS servers / Resolver approach
Posted by Oliver Wulff <ow...@talend.com>.
Hi Fran
Has the attachment been removed? Maybe zip it before.
Thanks
------
Oliver Wulff
http://owulff.blogspot.com<http://owulff.blogspot.com/>
Solution Architect
Talend Application Integration Division http://www.talend.com
________________________________
Von: Francisco Serrano [francisco.serrano@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