unity-idm-discuss — Unity discussion and support

[Unity-idm-discuss] Group administrator role

[Sander A. <sa....@fz...>]

Dear Krzysztof,
we encountered an issue with the group administrator role. If I
remember correctly we did not cover the case where we have dedicated
managers for subgroups. At the moment the group administrator is
administrators of all subgroups and the maingroup itself.

We have now reqeusts for the groupmanagement where multiple subgroups
are managed by dedicated people but they should not have the
administrator privileges in upper groups.

E.g.
user1 is admin of /ABC and everything below.
user2 is admin of /ABC/DEF and everything below but not of /ABC and
/ABC/GHI
user3 is admin of /ABC/GHI and everything below but not of /ABC and
/ABC/DEF

Is it possible to adopt the group administrator role in the way that it
is only granted downwards in the tree and not upwards?

Cheers,
Sander
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Naming of groups created via upman

[Sander A. <sa....@fz...>]

Hi Krzysztof,
I think, having access to the group-displaynames in the
translationprofile would be very helpful. In this case we could
transform them with mvel statments to our needs. E.g. We could
transform /ABC/DEF into urn:geant_h-
df.de:group:MyTestGroup:subgroup1#...

where /ABC is MyTestGroup and .../DEF subgroup1 within MyTestGroup.

In this case you do not need to carry about the released information or
change the unity behaviour. Maybe other users want/need the current
behaviour.

Having this possibility would allow to create the entitlement according
to AARC G002 automatically for all groups, instead using attribute
statements.

Best regards,
Sander

On Tue, 2020-08-11 at 09:12 +0200, Marcus Hardt wrote:
> On 08/10/20 19:26, Krzysztof Benedyczak wrote:
> > Hi Sander,
> > 
> > W dniu 04.08.2020 o 15:01, Sander Apweiler pisze:
> > > Hi Krzysztof,
> > > 
> > > On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote:
> > > > Morning Sander,
> > > > 
> > > > W dniu 03.08.2020 o 08:39, Sander Apweiler pisze:
> > > > > Good morning Krzysztof,
> > > > > I agree that identifiers are needed. But is there a
> > > > > possibility to
> > > > > grab
> > > > > the displayname of a group, e.g. in output translation
> > > > > profile? In
> > > > > this
> > > > > case we could release the group membership information like
> > > > > the
> > > > > group
> > > > > administrators and service providers would expect them.
> > > > > 
> > > > > I'll give you an example. We have a group m-team which is
> > > > > managed
> > > > > by a
> > > > > group administrator. He created a subgroup feudal-developers
> > > > > and
> > > > > asked
> > > > > specific service providers to support his group /m-
> > > > > team/feudal-
> > > > > developers but the service provider only see /m-team/NNE09.
> > > > > 
> > > > > Having the possibility to access the displayname, we could
> > > > > create a
> > > > > new
> > > > > attribute containing the expected information.
> > > > Hmm I wonder whether this is the right path. Shouldn't this be
> > > > opposite?
> > > I would agree in a very closed SP audience, only. If you have a
> > > broader
> > > audience which are part of multiple federations, this may become
> > > problematically. You would need to have a unique identifier
> > > across
> > > several IdPs, which can not be guaranteed. And in this case you
> > > do not
> > > need to carry about the uniqueness of the information anymore.
> > 
> > I don't udnerstand. You have many clients (SPs), OK. There is Upman
> > instance
> > with some groups. SPs get attribute with group id (say /zxc). Where
> > is the
> > problem that instead you need "/my-important-group"?
> > 
> > I don't understand the passage about unique identifier across
> > several IdPs?
> 
> There are multiple points.
> 
> Firstly, if SPs only obtain an identifier (rather than a name) it
> will be very difficult to make sure that name is the same everywhere.
> 
> That is why everybody simply sent a list of groups.
> 
> Then people realized that different IdPs might issue the same group
> name
> in different contexts. That is why we wrote AARC-G002, that defines
> globally unique group names (using the eduperson_entitlement)
> 
> Then came reality, that struck us the fact that some SPs (the stupid
> SPs
> from below) simply display "the entry" (i.e. either group or
> eduperson_entitlement) to the user. For that GUIDs suck, for those
> group
> lists are acceptable, but those services can only bind to one proxy.
> 
> It be useful (I guess) for Sander, if the groups in unity correspond
> uniquely to their G002 representation.
> 
> Unity internal identifiers should not be exposed outside of unity.
> 
>  
> > > Another problem are stupid SPs which consume the information
> > > directly
> > > and displays it to the users. One example is Nextcloud which is
> > > able to
> > > consume the groups from IdP (unity in this case). But Nextcloud
> > > will
> > > create the groups with the names released by the IdP and if the
> > > user
> > > want to share information with the group, they need to know the
> > > identifier.
> > 
> > Properly this should be realized as follows: IdP (upman) releases
> > group id
> > (hidden to the user) and displayed name (presented). Internally
> > group id is
> > used.
> > 
> > If this is not doable (i.e. the software can not distinguish
> > identifier from
> > its displaied form) the only thing we can do is to have same
> > displayed name
> > and group id.
> 
> I'm not sure why the identifier needs to be exposed at all, but there
> may
> be use cases that I don't know.
> 
> M.
> 
>  
> > This would be extra feature in upman, an extra mode: group creation
> > would
> > use displayed name as group id. We can do it, but note that as soon
> > as
> > somebody changes group displayed name in upman (or unity console)
> > you will
> > have semantic mess in the infrastructure.
> > 
> > Does the above address your problem?
> > 
> > Cheers,
> > Krzysztof
> > 
> > 
> > 
> > _______________________________________________
> > Unity-idm-discuss mailing list
> > Uni...@li...
> > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Naming of groups created via upman

[Marcus H. <ha...@ki...>]

On 08/10/20 19:26, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> W dniu 04.08.2020 o 15:01, Sander Apweiler pisze:
> > Hi Krzysztof,
> > 
> > On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote:
> > > Morning Sander,
> > > 
> > > W dniu 03.08.2020 o 08:39, Sander Apweiler pisze:
> > > > Good morning Krzysztof,
> > > > I agree that identifiers are needed. But is there a possibility to
> > > > grab
> > > > the displayname of a group, e.g. in output translation profile? In
> > > > this
> > > > case we could release the group membership information like the
> > > > group
> > > > administrators and service providers would expect them.
> > > > 
> > > > I'll give you an example. We have a group m-team which is managed
> > > > by a
> > > > group administrator. He created a subgroup feudal-developers and
> > > > asked
> > > > specific service providers to support his group /m-team/feudal-
> > > > developers but the service provider only see /m-team/NNE09.
> > > > 
> > > > Having the possibility to access the displayname, we could create a
> > > > new
> > > > attribute containing the expected information.
> > > Hmm I wonder whether this is the right path. Shouldn't this be
> > > opposite?
> > I would agree in a very closed SP audience, only. If you have a broader
> > audience which are part of multiple federations, this may become
> > problematically. You would need to have a unique identifier across
> > several IdPs, which can not be guaranteed. And in this case you do not
> > need to carry about the uniqueness of the information anymore.
> 
> I don't udnerstand. You have many clients (SPs), OK. There is Upman instance
> with some groups. SPs get attribute with group id (say /zxc). Where is the
> problem that instead you need "/my-important-group"?
> 
> I don't understand the passage about unique identifier across several IdPs?

There are multiple points.

Firstly, if SPs only obtain an identifier (rather than a name) it
will be very difficult to make sure that name is the same everywhere.

That is why everybody simply sent a list of groups.

Then people realized that different IdPs might issue the same group name
in different contexts. That is why we wrote AARC-G002, that defines
globally unique group names (using the eduperson_entitlement)

Then came reality, that struck us the fact that some SPs (the stupid SPs
from below) simply display "the entry" (i.e. either group or
eduperson_entitlement) to the user. For that GUIDs suck, for those group
lists are acceptable, but those services can only bind to one proxy.

It be useful (I guess) for Sander, if the groups in unity correspond
uniquely to their G002 representation.

Unity internal identifiers should not be exposed outside of unity.

 
> > Another problem are stupid SPs which consume the information directly
> > and displays it to the users. One example is Nextcloud which is able to
> > consume the groups from IdP (unity in this case). But Nextcloud will
> > create the groups with the names released by the IdP and if the user
> > want to share information with the group, they need to know the
> > identifier.
> 
> Properly this should be realized as follows: IdP (upman) releases group id
> (hidden to the user) and displayed name (presented). Internally group id is
> used.
> 
> If this is not doable (i.e. the software can not distinguish identifier from
> its displaied form) the only thing we can do is to have same displayed name
> and group id.

I'm not sure why the identifier needs to be exposed at all, but there may
be use cases that I don't know.

M.

 
> This would be extra feature in upman, an extra mode: group creation would
> use displayed name as group id. We can do it, but note that as soon as
> somebody changes group displayed name in upman (or unity console) you will
> have semantic mess in the infrastructure.
> 
> Does the above address your problem?
> 
> Cheers,
> Krzysztof
> 
> 
> 
> _______________________________________________
> Unity-idm-discuss mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss

-- 
Marcus.

Re: [Unity-idm-discuss] Redirect to SAML IdP is not working

[Sander A. <sa....@fz...>]

Dear Krzysztof,
I attached the extended log. I saw some problems with "Response header
too large" but I'm not sure who send this header.

Cheers,
Sander

I attached the On Mon, 2020-08-10 at 19:15 +0200, Krzysztof Benedyczak
wrote:
> Dear Sander,
> 
> W dniu 10.08.2020 o 06:58, Sander Apweiler pisze:
> > Dear Krzysztof,
> > we encountered an issue with the SAML IdP of CLARIN. We connected
> > this
> > IdP on two instance (b2access.eudat.eu and b2access-integration.fz-
> > juelich.de), both are running unity 3.2.2. Both are configured in
> > the
> > same way:
> > 
> > unity.saml.requester.metadataSource.clarin.url=
> > https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml
> > unity.saml.requester.metadataSource.clarin.perMetadataTranslationPr
> > ofile=clarinIdp
> > unity.saml.requester.metadataSource.clarin.perMetadataRegistrationF
> > orm=CLARIN-IDP
> > 
> > On the integration instance it works fine, but on the eudat.eu
> > instance
> > it stops since at least last week (here we found this issue) after
> > selecting the IdP with the URL:
> > 
> > https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef
> > 
> > The log file does not provide any further information (trace). I
> > attached the log and the SAML flow information from a user, where
> > you
> > see a 500 error. Did you see this problem before? We dropped
> > already
> > the IdP and add it new.
> 
> As this is easily reproducible (I was able on you instance without
> any 
> trouble):
> 
> 1. pls try to obtain logged error from your server. Try to enable
> even 
> full TRACE (all subsystems) for a sec, and trigger the issue. There 
> should be something logged on jetty or vaadin level
> 
> 2. if you fail with the above try to provide your authenticator 
> configuration, so that it can be configured on my end. Then I can try
> to 
> debug it. It would be perfect if you replicated this problem with
> other 
> environment - there must be some difference between your testbed and 
> prod instance.
> 
> 
> Cheers
> Krzysztof
> 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Naming of groups created via upman

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

Hi Sander,

W dniu 04.08.2020 o 15:01, Sander Apweiler pisze:
> Hi Krzysztof,
>
> On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote:
>> Morning Sander,
>>
>> W dniu 03.08.2020 o 08:39, Sander Apweiler pisze:
>>> Good morning Krzysztof,
>>> I agree that identifiers are needed. But is there a possibility to
>>> grab
>>> the displayname of a group, e.g. in output translation profile? In
>>> this
>>> case we could release the group membership information like the
>>> group
>>> administrators and service providers would expect them.
>>>
>>> I'll give you an example. We have a group m-team which is managed
>>> by a
>>> group administrator. He created a subgroup feudal-developers and
>>> asked
>>> specific service providers to support his group /m-team/feudal-
>>> developers but the service provider only see /m-team/NNE09.
>>>
>>> Having the possibility to access the displayname, we could create a
>>> new
>>> attribute containing the expected information.
>> Hmm I wonder whether this is the right path. Shouldn't this be
>> opposite?
> I would agree in a very closed SP audience, only. If you have a broader
> audience which are part of multiple federations, this may become
> problematically. You would need to have a unique identifier across
> several IdPs, which can not be guaranteed. And in this case you do not
> need to carry about the uniqueness of the information anymore.

I don't udnerstand. You have many clients (SPs), OK. There is Upman 
instance with some groups. SPs get attribute with group id (say /zxc). 
Where is the problem that instead you need "/my-important-group"?

I don't understand the passage about unique identifier across several IdPs?

> Another problem are stupid SPs which consume the information directly
> and displays it to the users. One example is Nextcloud which is able to
> consume the groups from IdP (unity in this case). But Nextcloud will
> create the groups with the names released by the IdP and if the user
> want to share information with the group, they need to know the
> identifier.

Properly this should be realized as follows: IdP (upman) releases group 
id (hidden to the user) and displayed name (presented). Internally group 
id is used.

If this is not doable (i.e. the software can not distinguish identifier 
from its displaied form) the only thing we can do is to have same 
displayed name and group id.

This would be extra feature in upman, an extra mode: group creation 
would use displayed name as group id. We can do it, but note that as 
soon as somebody changes group displayed name in upman (or unity 
console) you will have semantic mess in the infrastructure.

Does the above address your problem?

Cheers,
Krzysztof

Re: [Unity-idm-discuss] Redirect to SAML IdP is not working

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

Dear Sander,

W dniu 10.08.2020 o 06:58, Sander Apweiler pisze:
> Dear Krzysztof,
> we encountered an issue with the SAML IdP of CLARIN. We connected this
> IdP on two instance (b2access.eudat.eu and b2access-integration.fz-
> juelich.de), both are running unity 3.2.2. Both are configured in the
> same way:
>
> unity.saml.requester.metadataSource.clarin.url=https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml
> unity.saml.requester.metadataSource.clarin.perMetadataTranslationProfile=clarinIdp
> unity.saml.requester.metadataSource.clarin.perMetadataRegistrationForm=CLARIN-IDP
>
> On the integration instance it works fine, but on the eudat.eu instance
> it stops since at least last week (here we found this issue) after
> selecting the IdP with the URL:
>
> https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef
>
> The log file does not provide any further information (trace). I
> attached the log and the SAML flow information from a user, where you
> see a 500 error. Did you see this problem before? We dropped already
> the IdP and add it new.

As this is easily reproducible (I was able on you instance without any 
trouble):

1. pls try to obtain logged error from your server. Try to enable even 
full TRACE (all subsystems) for a sec, and trigger the issue. There 
should be something logged on jetty or vaadin level

2. if you fail with the above try to provide your authenticator 
configuration, so that it can be configured on my end. Then I can try to 
debug it. It would be perfect if you replicated this problem with other 
environment - there must be some difference between your testbed and 
prod instance.


Cheers
Krzysztof

[Unity-idm-discuss] Redirect to SAML IdP is not working

[Sander A. <sa....@fz...>]

Dear Krzysztof,
we encountered an issue with the SAML IdP of CLARIN. We connected this
IdP on two instance (b2access.eudat.eu and b2access-integration.fz-
juelich.de), both are running unity 3.2.2. Both are configured in the
same way:

unity.saml.requester.metadataSource.clarin.url=https://infra.clarin.eu/aai/prod_md_about_clarin_erics_idp.xml
unity.saml.requester.metadataSource.clarin.perMetadataTranslationProfile=clarinIdp
unity.saml.requester.metadataSource.clarin.perMetadataRegistrationForm=CLARIN-IDP

On the integration instance it works fine, but on the eudat.eu instance
it stops since at least last week (here we found this issue) after
selecting the IdP with the URL:

https://b2access.eudat.eu/home/?redirectToIdP=d9c934ff-1b81-40cd-a77d-ee1c6c26a3ef

The log file does not provide any further information (trace). I
attached the log and the SAML flow information from a user, where you
see a 500 error. Did you see this problem before? We dropped already
the IdP and add it new.

Cheers,
Sander
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Naming of groups created via upman

[Sander A. <sa....@fz...>]

Hi Krzysztof,

On Tue, 2020-08-04 at 09:56 +0200, Krzysztof Benedyczak wrote:
> Morning Sander,
> 
> W dniu 03.08.2020 o 08:39, Sander Apweiler pisze:
> > Good morning Krzysztof,
> > I agree that identifiers are needed. But is there a possibility to
> > grab
> > the displayname of a group, e.g. in output translation profile? In
> > this
> > case we could release the group membership information like the
> > group
> > administrators and service providers would expect them.
> > 
> > I'll give you an example. We have a group m-team which is managed
> > by a
> > group administrator. He created a subgroup feudal-developers and
> > asked
> > specific service providers to support his group /m-team/feudal-
> > developers but the service provider only see /m-team/NNE09.
> > 
> > Having the possibility to access the displayname, we could create a
> > new
> > attribute containing the expected information.
> 
> Hmm I wonder whether this is the right path. Shouldn't this be
> opposite? 
I would agree in a very closed SP audience, only. If you have a broader
audience which are part of multiple federations, this may become
problematically. You would need to have a unique identifier across
several IdPs, which can not be guaranteed. And in this case you do not
need to carry about the uniqueness of the information anymore.

Another problem are stupid SPs which consume the information directly
and displays it to the users. One example is Nextcloud which is able to
consume the groups from IdP (unity in this case). But Nextcloud will
create the groups with the names released by the IdP and if the user
want to share information with the group, they need to know the
identifier.

The next scenario is that a research community might have their groups
on several environments and want to have the same name on every
services. Here does the identifier also not work. Sadly such small
things might make the decision if the service is used or not.

To make it short there are scenarios where the opposite flow does not
work.
> I.e. on output profile/protocol etc I would rather send 'NNE09' as
> the 
> identifier and configure all policies around this - this is stable 
> identifier. If you program around displayed name then... who knows
> what 
> needs to be updated after some upman admin "improves" the displayed
> name?
Changing the display name would be the the short was for creating a new
group with the same members and removing the old group. Which would
lead of course to changed access permissions on the SP, which use the
group based access. Having no access to the resources are also possible
in this case.
> 
> I agree that giving access to displayed name (also in output
> profile) 
> makes sense in general, to add some human readable context (useful
> e.g. 
> for debuggin, initial config) but the base thing for me is the
> stable 
> identifier.
> 
> What do you think?
I agree that having a unique identifier is necessary for unity. But
there are different scenarios where the displayname need to be released
to the service providers instead of the identifier.

Cheers,
Sander
> 
> KB
> 
> 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Naming of groups created via upman

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

Morning Sander,

W dniu 03.08.2020 o 08:39, Sander Apweiler pisze:
> Good morning Krzysztof,
> I agree that identifiers are needed. But is there a possibility to grab
> the displayname of a group, e.g. in output translation profile? In this
> case we could release the group membership information like the group
> administrators and service providers would expect them.
>
> I'll give you an example. We have a group m-team which is managed by a
> group administrator. He created a subgroup feudal-developers and asked
> specific service providers to support his group /m-team/feudal-
> developers but the service provider only see /m-team/NNE09.
>
> Having the possibility to access the displayname, we could create a new
> attribute containing the expected information.

Hmm I wonder whether this is the right path. Shouldn't this be opposite? 
I.e. on output profile/protocol etc I would rather send 'NNE09' as the 
identifier and configure all policies around this - this is stable 
identifier. If you program around displayed name then... who knows what 
needs to be updated after some upman admin "improves" the displayed name?

I agree that giving access to displayed name (also in output profile) 
makes sense in general, to add some human readable context (useful e.g. 
for debuggin, initial config) but the base thing for me is the stable 
identifier.

What do you think?

KB

Re: [Unity-idm-discuss] Issue with remember me function

[Marcus H. <ha...@ki...>]

On 08/03/20 09:20, Marcus Hardt wrote:
> On 08/01/20 23:57, Krzysztof Benedyczak wrote:
> > Sander,
> > 
> > W dniu 27.07.2020 o 07:36, Sander Apweiler pisze:
> > > Good morning Krzysztof,
> > > 
> > > On Sat, 2020-07-25 at 16:03 +0200, Krzysztof Benedyczak wrote:
> > > > Hi Sander,
> > > > 
> > > > W dniu 20.07.2020 o 12:34, Sander Apweiler pisze:
> > > > > Yes it is stored. See attachment.
> > > > > > 2. what are the settings in authentication UI configuration? Do
> > > > > > you
> > > > > > have
> > > > > > "show last used option..." selected on the endpoint in question?
> > > > > Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout?
> > > > > We use the default value.
> > > > No I meant this:
> > > > 
> > > > unity.endpoint.web .authnShowLastOptionOnly
> > > > 
> > > > do you have it set to true? Can you check up your endpoint config in
> > > > Console?
> > > The option is not set in config files, so I guess it uses the default
> > > value true. Within the configuration in console endpoint, it indicates
> > > that it is true. See attachments.
> > > > Anyway this works for me. I can only suspect some problem with authN
> > > > options autogenerated from saml metadata.
> > > > 
> > > > > > 3. it doesn't work for saml only or for arbitrary authentication
> > > > > > options?
> > > > > It does not work for all endpoints.
> > > > > 
> > > > I meant: whether this problem occurs only with SAML sign-in using
> > > > some federation, or it also doesn't work with other authN options
> > > > (e.g. password)?
> > > It is working for no authN. Not for SAML federation and also not for
> > > password, where password authentication is possible.
> > > 
> > Well, I've tried this in several variants and all were working on my end
> > flawlessly.
> > 
> > I can't give you any better hint, then to try to minimize the problem area.
> > Perhaps you can try to setup a simple test endpoint (e.g. homeUI) add to it
> > 2 authN options (e.g. password and one oauth) and try on it? If it works (by
> > far it should) then I'd try to add more setting from an endpoint which is
> > not working. If it doesn't work, let me know the precise config of the
> > endpoint.
> 
> From what I saw, the problem does not show with every SAML IdP. I saw a
> screenshare of DKFZ users where it worked, but I think that it does not
> work properly for KIT and HMGU users.

Sorry, I meant HZDR users.
 
> -- 
> Marcus.

Re: [Unity-idm-discuss] Issue with remember me function

[Marcus H. <ha...@ki...>]

On 08/01/20 23:57, Krzysztof Benedyczak wrote:
> Sander,
> 
> W dniu 27.07.2020 o 07:36, Sander Apweiler pisze:
> > Good morning Krzysztof,
> > 
> > On Sat, 2020-07-25 at 16:03 +0200, Krzysztof Benedyczak wrote:
> > > Hi Sander,
> > > 
> > > W dniu 20.07.2020 o 12:34, Sander Apweiler pisze:
> > > > Yes it is stored. See attachment.
> > > > > 2. what are the settings in authentication UI configuration? Do
> > > > > you
> > > > > have
> > > > > "show last used option..." selected on the endpoint in question?
> > > > Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout?
> > > > We use the default value.
> > > No I meant this:
> > > 
> > > unity.endpoint.web .authnShowLastOptionOnly
> > > 
> > > do you have it set to true? Can you check up your endpoint config in
> > > Console?
> > The option is not set in config files, so I guess it uses the default
> > value true. Within the configuration in console endpoint, it indicates
> > that it is true. See attachments.
> > > Anyway this works for me. I can only suspect some problem with authN
> > > options autogenerated from saml metadata.
> > > 
> > > > > 3. it doesn't work for saml only or for arbitrary authentication
> > > > > options?
> > > > It does not work for all endpoints.
> > > > 
> > > I meant: whether this problem occurs only with SAML sign-in using
> > > some federation, or it also doesn't work with other authN options
> > > (e.g. password)?
> > It is working for no authN. Not for SAML federation and also not for
> > password, where password authentication is possible.
> > 
> Well, I've tried this in several variants and all were working on my end
> flawlessly.
> 
> I can't give you any better hint, then to try to minimize the problem area.
> Perhaps you can try to setup a simple test endpoint (e.g. homeUI) add to it
> 2 authN options (e.g. password and one oauth) and try on it? If it works (by
> far it should) then I'd try to add more setting from an endpoint which is
> not working. If it doesn't work, let me know the precise config of the
> endpoint.

From what I saw, the problem does not show with every SAML IdP. I saw a
screenshare of DKFZ users where it worked, but I think that it does not
work properly for KIT and HMGU users.

-- 
Marcus.

Re: [Unity-idm-discuss] Naming of groups created via upman

[Sander A. <sa....@fz...>]

Good morning Krzysztof,
I agree that identifiers are needed. But is there a possibility to grab
the displayname of a group, e.g. in output translation profile? In this
case we could release the group membership information like the group
administrators and service providers would expect them.

I'll give you an example. We have a group m-team which is managed by a
group administrator. He created a subgroup feudal-developers and asked
specific service providers to support his group /m-team/feudal-
developers but the service provider only see /m-team/NNE09.

Having the possibility to access the displayname, we could create a new
attribute containing the expected information.

Cheers,
Sander

On Sun, 2020-08-02 at 00:05 +0200, Krzysztof Benedyczak wrote:
> Dear Sander,
> 
> W dniu 31.07.2020 o 07:49, Sander Apweiler pisze:
> > Dear Krzysztof,
> > 
> > We encountered a problem with the names of groups, which was
> > created by
> > groupadministrators in upman endpoint. The name of the group which
> > is
> > released in groups attribute differs from the name which entered
> > the
> > user. It seems that unity creates a name randomly and the entered
> > name
> > is only used as display name.
> > 
> > I agree that the group administrators should only enter one name
> > and
> > not two like the unity administrators can do. But the information
> > is
> > used for group based access management on service provider level.
> > If
> > the groupname differs from the name which was entered by the group
> > administrators, this is not possible.
> > 
> > What is the reason for the randomly generated grounames? Can this
> > behaviour changed?
> 
> The group "internal" name, or its identifier, is set in stone. On
> the 
> other hand the displayed name can be changed at will.
> 
> If admin can define the internal name, then it will have a semantic
> name 
> typically. And this leads to troubles ("err I named it /cookies, but 
> should be /chockolate-bars really"). Also group names when used 
> externally should not relay on displayed name but on some stable id
> - 
> what is the internal name.
> 
> BTW in the full unity this should be the same, and is not only
> because 
> of the legacy of in-file configurations, where software can not
> assign 
> ids on its own.
> 
> All in all I would advise to simply use the identifiers externally, 
> especially in policies. If this is hard let me know why precisely; 
> chances are I'll be able to help as we use this approach in many 
> non-upman scenarios too. Or if not, we can think about an improvement
> then.
> 
> Best
> Krzysztof
> 
> 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Naming of groups created via upman

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

Dear Sander,

W dniu 31.07.2020 o 07:49, Sander Apweiler pisze:
> Dear Krzysztof,
>
> We encountered a problem with the names of groups, which was created by
> groupadministrators in upman endpoint. The name of the group which is
> released in groups attribute differs from the name which entered the
> user. It seems that unity creates a name randomly and the entered name
> is only used as display name.
>
> I agree that the group administrators should only enter one name and
> not two like the unity administrators can do. But the information is
> used for group based access management on service provider level. If
> the groupname differs from the name which was entered by the group
> administrators, this is not possible.
>
> What is the reason for the randomly generated grounames? Can this
> behaviour changed?

The group "internal" name, or its identifier, is set in stone. On the 
other hand the displayed name can be changed at will.

If admin can define the internal name, then it will have a semantic name 
typically. And this leads to troubles ("err I named it /cookies, but 
should be /chockolate-bars really"). Also group names when used 
externally should not relay on displayed name but on some stable id - 
what is the internal name.

BTW in the full unity this should be the same, and is not only because 
of the legacy of in-file configurations, where software can not assign 
ids on its own.

All in all I would advise to simply use the identifiers externally, 
especially in policies. If this is hard let me know why precisely; 
chances are I'll be able to help as we use this approach in many 
non-upman scenarios too. Or if not, we can think about an improvement then.

Best
Krzysztof

Re: [Unity-idm-discuss] Issue with remember me function

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

Sander,

W dniu 27.07.2020 o 07:36, Sander Apweiler pisze:
> Good morning Krzysztof,
>
> On Sat, 2020-07-25 at 16:03 +0200, Krzysztof Benedyczak wrote:
>> Hi Sander,
>>
>> W dniu 20.07.2020 o 12:34, Sander Apweiler pisze:
>>> Yes it is stored. See attachment.
>>>> 2. what are the settings in authentication UI configuration? Do
>>>> you
>>>> have
>>>> "show last used option..." selected on the endpoint in question?
>>> Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout?
>>> We use the default value.
>> No I meant this:
>>
>> unity.endpoint.web .authnShowLastOptionOnly
>>
>> do you have it set to true? Can you check up your endpoint config in
>> Console?
> The option is not set in config files, so I guess it uses the default
> value true. Within the configuration in console endpoint, it indicates
> that it is true. See attachments.
>> Anyway this works for me. I can only suspect some problem with authN
>> options autogenerated from saml metadata.
>>
>>>> 3. it doesn't work for saml only or for arbitrary authentication
>>>> options?
>>> It does not work for all endpoints.
>>>
>> I meant: whether this problem occurs only with SAML sign-in using
>> some federation, or it also doesn't work with other authN options
>> (e.g. password)?
> It is working for no authN. Not for SAML federation and also not for
> password, where password authentication is possible.
>
Well, I've tried this in several variants and all were working on my end 
flawlessly.

I can't give you any better hint, then to try to minimize the problem 
area. Perhaps you can try to setup a simple test endpoint (e.g. homeUI) 
add to it 2 authN options (e.g. password and one oauth) and try on it? 
If it works (by far it should) then I'd try to add more setting from an 
endpoint which is not working. If it doesn't work, let me know the 
precise config of the endpoint.


Cheers,
Krzysztof

Re: [Unity-idm-discuss] fail Authentication action in translation profile

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

Hi Sander,

W dniu 20.07.2020 o 14:34, Sander Apweiler pisze:
> Hi Krzysztof,
> we discussed it internally and having the possibility to configure an
> return/forward URL would be the best in our opinion. We could send the
> users to a specific page where they get further information or could
> request access to the service.
>

OK, I've opened a ticket. However this is bit messy (touches many 
places: SAML and OAuth flows, handling not in the profile really) so no 
strong promises that this will fit into the next version.


Cheers,
Krzysztof

[Unity-idm-discuss] Naming of groups created via upman

[Sander A. <sa....@fz...>]

Dear Krzysztof,

We encountered a problem with the names of groups, which was created by
groupadministrators in upman endpoint. The name of the group which is
released in groups attribute differs from the name which entered the
user. It seems that unity creates a name randomly and the entered name
is only used as display name.

I agree that the group administrators should only enter one name and
not two like the unity administrators can do. But the information is
used for group based access management on service provider level. If
the groupname differs from the name which was entered by the group
administrators, this is not possible.

What is the reason for the randomly generated grounames? Can this
behaviour changed?

Cheers,
Sander
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

[Unity-idm-discuss] 3.3.1 revision released

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

Dear Subscribers,

We have released 3.3.1 revision, fixing and improving 3.3.0 in several 
cases. While none of the issues were critical, there are several 
improvements that you may find useful, as improved email validation or 
fix in editor of certain group attribute statements.

What is more, this release enables use of SMS and OTP credential as a 
2nd factor credential for users who posses neither email nor username 
identity.

More details are available in Downloads 
<https://www.unity-idm.eu/downloads/>

Best regards,
Krzysztof

Re: [Unity-idm-discuss] Issue with remember me function

[Sander A. <sa....@fz...>]

Good morning Krzysztof,

On Sat, 2020-07-25 at 16:03 +0200, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> W dniu 20.07.2020 o 12:34, Sander Apweiler pisze:
> > Yes it is stored. See attachment. 
> > > 2. what are the settings in authentication UI configuration? Do
> > > you
> > > have 
> > > "show last used option..." selected on the endpoint in question?
> > 
> > Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout?
> > We use the default value.
> 
> No I meant this:
> 
> unity.endpoint.web .authnShowLastOptionOnly
> 
> do you have it set to true? Can you check up your endpoint config in
> Console?
The option is not set in config files, so I guess it uses the default
value true. Within the configuration in console endpoint, it indicates
that it is true. See attachments.
> 
> Anyway this works for me. I can only suspect some problem with authN
> options autogenerated from saml metadata.
> 
> > > 3. it doesn't work for saml only or for arbitrary authentication
> > > options?
> > 
> > It does not work for all endpoints.
> > 
> 
> I meant: whether this problem occurs only with SAML sign-in using
> some federation, or it also doesn't work with other authN options
> (e.g. password)?
It is working for no authN. Not for SAML federation and also not for
password, where password authentication is possible.

Best regards,
Sander
> 
> 
> 
> Best
> Krzysztof
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Issue with remember me function

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

Hi Sander,

W dniu 20.07.2020 o 12:34, Sander Apweiler pisze:
> Yes it is stored. See attachment.
>> 2. what are the settings in authentication UI configuration? Do you
>> have
>> "show last used option..." selected on the endpoint in question?
> Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout?
> We use the default value.

No I meant this:

|unity.endpoint.web| |.authnShowLastOptionOnly|

do you have it set to true? Can you check up your endpoint config in 
Console?

Anyway this works for me. I can only suspect some problem with authN 
options autogenerated from saml metadata.

>> 3. it doesn't work for saml only or for arbitrary authentication
>> options?
> It does not work for all endpoints.
>
I meant: whether this problem occurs only with SAML sign-in using some 
federation, or it also doesn't work with other authN options (e.g. 
password)?


Best
Krzysztof

Re: [Unity-idm-discuss] Error in atttribute statements

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

Hi Sander,

W dniu 22.07.2020 o 07:23, Sander Apweiler pisze:
> Good morning Krzysztof,
> in the version 3.3.0 I got an error with attribute statements. I can
> create them without errors but when I want to edit them, I got the
> attached error. The log has a nullpointer exception. The statement
> itself works.


Thanks for the report - UI regression affecting fixed attribute 
statement editing (rarely used so was unnoticed).

Fixed, will be in 3.3.1.

Best
KB

[Unity-idm-discuss] Error in atttribute statements

[Sander A. <sa....@fz...>]

Good morning Krzysztof,
in the version 3.3.0 I got an error with attribute statements. I can
create them without errors but when I want to edit them, I got the
attached error. The log has a nullpointer exception. The statement
itself works.

Best regards,
Sander
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] fail Authentication action in translation profile

[Sander A. <sa....@fz...>]

Hi Krzysztof,
we discussed it internally and having the possibility to configure an
return/forward URL would be the best in our opinion. We could send the
users to a specific page where they get further information or could
request access to the service.

Best regards,
Sander

On Mon, 2020-07-20 at 12:25 +0200, Krzysztof Benedyczak wrote:
> Hi,
> 
> W dniu 17.07.2020 o 08:28, Sander Apweiler pisze:
> > Good morning Krzysztof,
> > we tested the fail Authentication action in the translation
> > profiles to
> > do a lightweight ABAC/authorisation within unity for service who
> > can't
> > do it by itself.
> > We encountered some problems/not optimal behaviour in it. The error
> > message is only send to service, but not to the users. The services
> > can
> > not handle such specific error messages and the user get a very
> > strange
> > error at the service. E.g. the error of Nextcloud is:
> > "Account not provisioned.
> > Your account is not provisioned, access to this service is thus not
> > possible."
> > 
> > The user do not really understand why the login fails. From our
> > point
> > of view it would be great if the failed authentication error is
> > shown
> > to the user, maybe with the possibility to login with another
> > account.
> > Do you see a possibility to extend the fail authentication
> > behaviour?
> 
> Yes, we can extend this action. Adding a checkbox: "show error 
> internally" + its implementation is easy. However, is it going to be 
> useful? Just to stop the user on unity error page? Shall we redirect 
> back to the service (so the error, perhaps wrong if the service
> doesn't 
> implement error handling correctly, will be shown again)? Or redirect
> to 
> other address (like article in help center)?
> 
> Best,
> KB
> 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] Issue with remember me function

[Sander A. <sa....@fz...>]

Hi Krzysztof,

On Mon, 2020-07-20 at 12:18 +0200, Krzysztof Benedyczak wrote:
> Hi Sander,
> 
> W dniu 17.07.2020 o 08:12, Sander Apweiler pisze:
> > Good morning Krzysztof,
> > 
> > we have an issue on one of our four unity (3.2.2) instances with
> > the
> > remember me function. It is not working. When I log out from a
> > service
> > and from unity, by passing the session lifetime or logging out in a
> > second browser tab, and try to re-login, I see all connected IdPs
> > but
> > not the screen with my last one. This issue appears with all
> > browsers
> > and with different users. The log does not show any errors. The
> > remember me configuration is the default configuration. Do you have
> > seen this issue/behaviour before?
> 
> It seems you are referring to screen showing last used
> authentication 
> option, not the "remember me" setting which is skipping one or all
> authN 
> factors on a trusted device?
Yes I mean showing the last used authentication. Sorry for the
misswording.
> 
> 
> Assuming so:
> 
> 1. can you check whether you have "last used" cookie stored for
> unity 
> instance origin? What is the value? It should be stored immediately 
> after successful login.
Yes it is stored. See attachment.
> 
> 2. what are the settings in authentication UI configuration? Do you
> have 
> "show last used option..." selected on the endpoint in question?
Do you mean this one: unity.endpoint.web.authnLastOptionOnlyLayout?
We use the default value.
> 
> 3. it doesn't work for saml only or for arbitrary authentication
> options?
It does not work for all endpoints.

Best regards,
Sander
> 
> 
> Cheers,
> Krzysztof
> 
-- 
Federated Systems and Data
Juelich Supercomputing Centre

phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...

----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Volker Rieke
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt
-----------------------------------------------------------------------
-----------------------------------------------------------------------

Re: [Unity-idm-discuss] fail Authentication action in translation profile

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

Hi,

W dniu 17.07.2020 o 08:28, Sander Apweiler pisze:
> Good morning Krzysztof,
> we tested the fail Authentication action in the translation profiles to
> do a lightweight ABAC/authorisation within unity for service who can't
> do it by itself.
> We encountered some problems/not optimal behaviour in it. The error
> message is only send to service, but not to the users. The services can
> not handle such specific error messages and the user get a very strange
> error at the service. E.g. the error of Nextcloud is:
> "Account not provisioned.
> Your account is not provisioned, access to this service is thus not
> possible."
>
> The user do not really understand why the login fails. From our point
> of view it would be great if the failed authentication error is shown
> to the user, maybe with the possibility to login with another account.
> Do you see a possibility to extend the fail authentication behaviour?

Yes, we can extend this action. Adding a checkbox: "show error 
internally" + its implementation is easy. However, is it going to be 
useful? Just to stop the user on unity error page? Shall we redirect 
back to the service (so the error, perhaps wrong if the service doesn't 
implement error handling correctly, will be shown again)? Or redirect to 
other address (like article in help center)?

Best,
KB

Re: [Unity-idm-discuss] Issue with remember me function

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

Hi Sander,

W dniu 17.07.2020 o 08:12, Sander Apweiler pisze:
> Good morning Krzysztof,
>
> we have an issue on one of our four unity (3.2.2) instances with the
> remember me function. It is not working. When I log out from a service
> and from unity, by passing the session lifetime or logging out in a
> second browser tab, and try to re-login, I see all connected IdPs but
> not the screen with my last one. This issue appears with all browsers
> and with different users. The log does not show any errors. The
> remember me configuration is the default configuration. Do you have
> seen this issue/behaviour before?

It seems you are referring to screen showing last used authentication 
option, not the "remember me" setting which is skipping one or all authN 
factors on a trusted device?


Assuming so:

1. can you check whether you have "last used" cookie stored for unity 
instance origin? What is the value? It should be stored immediately 
after successful login.

2. what are the settings in authentication UI configuration? Do you have 
"show last used option..." selected on the endpoint in question?

3. it doesn't work for saml only or for arbitrary authentication options?


Cheers,
Krzysztof