AW: Several IDP-STS servers / Resolver approach

2012-01-23 Thread Oliver Wulff 
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 [owu...@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.serr...@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

AW: Several IDP-STS servers / Resolver approach

2012-01-18 Thread Oliver Wulff 
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.serr...@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 yo

AW: Several IDP-STS servers / Resolver approach

2012-01-17 Thread Oliver Wulff 
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
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
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

AW: Several IDP-STS servers / Resolver approach

2012-01-16 Thread Oliver Wulff 
Hi Fran



Has the attachment been removed? Maybe zip it before.



Thanks



--

Oliver Wulff

http://owulff.blogspot.com
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