Re: [Unity-idm-discuss] change attribute value type error

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

Hi Sander,

W dniu 09.11.2016 o 15:55, Sander Apweiler pisze:
> Hi Krzysztof,
>
> I copied the attribute values with REST API to a new one. After updating
> registration forms, translation profiles and config to the new attribute
> I found some problems or maybe bugs.
>
> 1) The old attribute named email and the new attribute named mail are
> stored in Unity. The following output translation profile is used for SPs:
> Condition: true
> Action: createAttribute
> attributeName: email
> expression: attr['mail']
>
> If this translation profile is used, Unity ignores the expression and
> send the value of the attribute "email" to the client. If there is no
> attribute named email, the expression works.

Yes, this is an expected behavior: createAttribute action is skipped if 
its attribute already exists. If you set logging level for translation 
to TRACE then you get the explicit message about this happening in log. 
As this was misleading for you I'm increasing the log level to: DEBUG.

Solution for your problem is to put (before the createAttribute rule) 
filterAttribute action, which removes the original 'email' attribute.


> 2) SAML clients can't use verifiableEmail attributes. I got an error
> from an SAML client because Unity sends within the response the
> following status:
> <urn:Status>
>         <urn:StatusCode
> Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
>         <urn:StatusMessage>pl.edu.icm.unity.types.basic.VerifiableEmail
> cannot be cast to java.lang.String</urn:StatusMessage>
> </urn:Status>
>
> So it seems that Unity can't cast the VerifiableEmail attribute in SAML
> context. For Oauth it works fine. Very bad is that unity logfiles has no
> errors. If I have a look in it, it seems that everything was fine.

I agree, this clearly signals some bug. In principle Unity should never 
cast its internal attribute value to SAML value, it should use a 
configured encoder. Of course there is such encoder for emails, and it 
is tested that this feature is working, i.e. I get SAML responses with 
emails in them.

Said so: can you please more details about a setup where I can reproduce 
this problem? If you could send me the complete config of SAML idp 
endpoint + profile is used then would be great.


> 3) In input translation profiles we use effect = CREATE_OR_UPDATE for
> attribute mapping. If you use this effect for verifiableEmail the user
> receives a confirmation email after every login (although the email
> address was confirmed). I would expect that it is send once at
> registration and a new confirmation mail is send if the email address
> has changed.

Well, this is bit tricky. The behavior is that Unity sets the email to 
unconfirmed after each login, because this is how you have configured 
your profile. And in effect you have confirmation request sent always.

In the majority of cases, when authN is delegated to external service, 
it can be trusted that the provided email was verified and local 
re-verification by unity should be skipped at all. You can achieve this 
by adding a constant suffix "[CONFIRMED]" to attribute value in your 
profile's expression - see section 7.4.4 in manual. I hope this is 
solving your issues.

However, if you want to do exactly as you wrote, i.e. verify the 
externally provided email with Unity, and re-do verification if email 
changes, then we need an extra feature. The problem is that unity must 
also allow for setting email attribute state from profile (some of OAuth 
services provide email verification status as a separate attribute). And 
this feature would become broken if your suggestion is simply 
implemented. THerefore if you need exactly such behavior please write, 
I'll think about some smart way to configure profile to act in such way.

Best,
Krzysztof