Re: [Unity-idm-discuss] Oauth-RP problem

[Krzysztof B. <kb...@un...>]

Hi Tim,

W dniu 05.05.2017 o 10:14, Tim Kreuzer pisze:
> Hi Krzysztof,
>
> Sander and I are working together on this.
>
>
> We send a Bearer access-token to UNICORE, which includes the user
> informations (tested by a manual HTTP Get-Request to /oauth2/tokeninfo
> and /oauth2/userinfo). We assume UNICORE is forwarding this token
> properly to unity (based on attached log - line 229), but we'll take a
> closer look at it. I updated the log4j.properties file to
>
> ...
> log4j.logger.unity.server=DEBUG
> log4j.logger.unity.server.oauth=TRACE
> log4j.logger.unity.server.rest=TRACE
> log4j.logger.unity.server.ws=TRACE
> ...
>
> and attached the result. This test was done with
>
> ...
> unity.oauth2-rp.verificationProtocol=internal
> ...
>
> and no defined unity.oauth2-rp.profileEndpoint (see attached log - line
> 230).

Yeah, this is clear now.

What is happening:
1) your token is sent by Unicore, and is validated fine
2) as you wrote the token verification is not using any profile URL. The 
result is that the data you associate with OAuth access token (using 
output profile) is never used. The only input OAuth verificator gets is 
the access token (it is verified).
3) Identity of the access token owner is an extra data provided out of 
the box by the internal token validator after it validates successfully 
the access token.
4) your input translation profile tries to match the obtained data about 
access token owner assuming that you have the x500Name attribute. But 
this attribute is absent - as said in (3) you have only the token's 
owner identity, nothing more.

So the harder way to fix this scenario is to configure getting the 
owner's data from the tokeninfo endpoint, i.e. the data associated with 
the access token by use of output profile. However this is an overkill 
in this situation: it would be useful if the token verification would be 
done remotely.
As verification is done on the same server that issued the tokenyou can 
simplify: your intput profile can reuse the owner's identifier to match 
the remote person to the local one (as in this scenario the remote 
person is also the local one so the matching is trivial). And at this 
point you have everything you need - a complete entity.

Action: mapIdentity
unityIdentityType: identifier
expression: id
(and you don't need the _CREATE flag, as this match will always work 
besides the case when the access token issuer is deleted between UNICORE 
manages to submit the request)

Also the output profile is not necessary then as you have the local 
access to all attributes.

Then UNICORE call is both authenticated as done by the original issuer 
and the answer (SOAP) will have the data for that principal.

HTH,
Krzysztof