Menu
▾
▴
unity-idm-discuss — Unity discussion and support
You can subscribe to this list here.
| 2014 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(7) |
Nov
(6) |
Dec
(11) |
| 2017 |
Jan
(10) |
Feb
(5) |
Mar
(27) |
Apr
(34) |
May
(25) |
Jun
(14) |
Jul
(7) |
Aug
(17) |
Sep
(11) |
Oct
(6) |
Nov
(14) |
Dec
(10) |
| 2018 |
Jan
(8) |
Feb
(19) |
Mar
(40) |
Apr
(9) |
May
(16) |
Jun
(23) |
Jul
(31) |
Aug
(7) |
Sep
(9) |
Oct
(6) |
Nov
(14) |
Dec
(19) |
| 2019 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(19) |
Dec
(14) |
| 2020 |
Jan
(10) |
Feb
(24) |
Mar
(49) |
Apr
(26) |
May
(12) |
Jun
(4) |
Jul
(13) |
Aug
(32) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
(16) |
| 2021 |
Jan
(2) |
Feb
(8) |
Mar
(15) |
Apr
(19) |
May
(5) |
Jun
(13) |
Jul
(6) |
Aug
(38) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(13) |
| 2022 |
Jan
(10) |
Feb
(21) |
Mar
(28) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(14) |
Aug
(13) |
Sep
(8) |
Oct
(29) |
Nov
(1) |
Dec
(21) |
| 2023 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(7) |
Jun
(10) |
Jul
(14) |
Aug
(17) |
Sep
(1) |
Oct
(9) |
Nov
(5) |
Dec
(14) |
| 2024 |
Jan
(12) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(24) |
Aug
(15) |
Sep
(1) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2025 |
Jan
(12) |
Feb
(2) |
Mar
(10) |
Apr
(11) |
May
(13) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sander A. <sa....@fz...> - 2018-06-06 07:54:11
|
Hi Krzysztof,
I have an issue with userhome in unity 2.4.2.
I added some additional attributes like o and loa but they are not
shown in userhome although they are set for the user. Also the account
linking, which is disabled in config is still shown.
Do you have any idea for this issue? See userhome config in attachment.
The config from core.module is:
unityServer.core.endpoints.userHome.endpointType=UserHomeUI
unityServer.core.endpoints.userHome.endpointConfigurationFile=${CONF}/m
odules/core/userhome.properties
unityServer.core.endpoints.userHome.contextPath=/home
unityServer.core.endpoints.userHome.endpointRealm=defaultRealm
unityServer.core.endpoints.userHome.endpointName=B2ACCESS user's
account
unityServer.core.endpoints.userHome.endpointAuthenticators=pwdWeb;certW
eb;samlWeb;oauthWeb;
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 Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
----------------------------------------------------------------------- |
|
From: Timo S. <Tim...@na...> - 2018-06-04 14:51:36
|
Hi Krzysztof, thanks and sorry for not reading this. Best, Timo On 04.06.2018 16:49, Krzysztof Benedyczak wrote: > Hi, > > W dniu 04.06.2018 o 16:36, Timo Strunk pisze: >> Hi everybody, >> >> starting the fresh Unity server currently leads to the following error: >> Script1.groovy: 11: unable to resolve class >> pl.edu.icm.unity.stdext.credential.PasswordToken >> Is there an issue tracker somewhere? > > As announced in upgrade notes of the 2.5.0 version: > > "For custom Groovy initialization script users only: package > |pl.edu.icm.unity.stdext.credential| was changed to > |pl.edu.icm.unity.stdext.credential.pass|, update the imports section." > > Best > Krzysztof -- Dr. Timo Strunk CTO Nanomatch GmbH Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen Germany Fon +49-721-608-26884 Web http://www.nanomatch.de CEO: Dr. Tobias Neumann Registered office of the association: 76344 Eggenstein-Leopoldshafen, Germany District court: Mannheim, HRB 720639 VAT-No. DE 297220880 Der Inhalt dieser E-Mail sowie sämtliche übermittelten Daten und Anhänge sind streng vertraulich. Wenn Sie nicht der vorgesehene Empfänger dieser E-Mail sind, bitten wir Sie zu beachten, dass jede Form der Kenntnisnahme, Vervielfältigung, Weitergabe oder Veröffentlichung der Inhalte dieser E-Mail unzulässig ist. Wir möchten Sie bitten, den Absender telefonisch oder per E-Mail zu informieren und diese E-Mail vollständig von Ihrem System zu entfernen. This e-mail message is intended solely for the use of the addressee and may contain legally privileged and confidential information. If you are not the intended recipient or his/her representative, please be advised that any dissemination, distribution, copying, or the use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and please delete this message and all attachments from your computer. |
|
From: Krzysztof B. <kb...@un...> - 2018-06-04 14:50:29
|
Hi, W dniu 04.06.2018 o 16:36, Timo Strunk pisze: > Hi everybody, > > starting the fresh Unity server currently leads to the following error: > Script1.groovy: 11: unable to resolve class > pl.edu.icm.unity.stdext.credential.PasswordToken > Is there an issue tracker somewhere? As announced in upgrade notes of the 2.5.0 version: "For custom Groovy initialization script users only: package |pl.edu.icm.unity.stdext.credential| was changed to |pl.edu.icm.unity.stdext.credential.pass|, update the imports section." Best Krzysztof |
|
From: Timo S. <Tim...@na...> - 2018-06-04 14:36:28
|
Hi everybody, starting the fresh Unity server currently leads to the following error: Script1.groovy: 11: unable to resolve class pl.edu.icm.unity.stdext.credential.PasswordToken Is there an issue tracker somewhere? Best, Timo -- Dr. Timo Strunk CTO Nanomatch GmbH Hermann-von-Helmholtz-Platz 1 76344 Eggenstein-Leopoldshafen Germany Fon +49-721-608-26884 Web http://www.nanomatch.de CEO: Dr. Tobias Neumann Registered office of the association: 76344 Eggenstein-Leopoldshafen, Germany District court: Mannheim, HRB 720639 VAT-No. DE 297220880 Der Inhalt dieser E-Mail sowie sämtliche übermittelten Daten und Anhänge sind streng vertraulich. Wenn Sie nicht der vorgesehene Empfänger dieser E-Mail sind, bitten wir Sie zu beachten, dass jede Form der Kenntnisnahme, Vervielfältigung, Weitergabe oder Veröffentlichung der Inhalte dieser E-Mail unzulässig ist. Wir möchten Sie bitten, den Absender telefonisch oder per E-Mail zu informieren und diese E-Mail vollständig von Ihrem System zu entfernen. This e-mail message is intended solely for the use of the addressee and may contain legally privileged and confidential information. If you are not the intended recipient or his/her representative, please be advised that any dissemination, distribution, copying, or the use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and please delete this message and all attachments from your computer. |
|
From: Krzysztof B. <kb...@un...> - 2018-06-02 15:14:47
|
Hi, W dniu 01.06.2018 o 13:52, Dimitri Nilsen pisze: > Hi, > > I lost "admin" password from my unity instance, is it possible to > reset/change it from the server command line somehow? > Or to set it to default "the!unity" again? You can set new admin account. see initialAdminUsername and initialAdminPassword options in documentation. Note that in latest versions of Unity the admin user is created with sys:password credential, so login using this credential must be enabled on your AdminUI endpoint. In older versions this was different and more complicated - see log after restart for details. Best Krzysztof |
|
From: Dimitri N. <dim...@ki...> - 2018-06-01 11:52:24
|
Hi, I lost "admin" password from my unity instance, is it possible to reset/change it from the server command line somehow? Or to set it to default "the!unity" again? Regards Dimitri |
|
From: Krzysztof B. <kb...@un...> - 2018-05-20 09:50:10
|
W dniu 14.05.2018 o 11:44, D Baum pisze: > Hi, > > On 09/05/18 23:46, Krzysztof Benedyczak wrote: >> While looking at your attached log it seems that Unity receives an >> unsigned request. > Yeah, I'm just not sure what really happens because the Shibboleth logs > kinda "claim" that signing happens: > > 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: > signing the message > 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: > message encoded, sending redirect to client > > >> I don't know details of your config - for >> validRequester have you configured trusted URLs (unless you use metadata >> to configure SLO)? You have an example at the very end of >> http://www.unity-idm.eu/documentation/unity-2.4.0/saml-howto.html#_using_single_logout_slo > I'm using metadata and Shibboleth has the following SingleLogoutServices > configured: > > <md:SingleLogoutService > Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" > Location="https://shibboleth/Shibboleth.sso/SLO/SOAP"/> > <md:SingleLogoutService > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" > Location="https://shibboleth/Shibboleth.sso/SLO/Redirect"/> > <md:SingleLogoutService > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > Location="https://shibboleth/Shibboleth.sso/SLO/POST"/> > <md:SingleLogoutService > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" > Location="https://shibboleth/Shibboleth.sso/SLO/Artifact"/> > >> Also one more hint: for redirect binding signing most likely won't be >> performed by initiating side: request would be too large for encoding >> into URL. > I'm calling https://shibboleth/Shibboleth.sso/Logout, so Shibboleth is > the initiating side (and it not signing would be consistent with the > unity logs). > > So one solution would be to comment out the redirect binding in the > Unity metadata used by Shibboleth, so that Shibboleth uses another > binding to send the SLO request? > Yes, you can try this. Also when debugging SLO try to capture what happens on web browser logs. This is super complex workflow, it is easy to mix up endpoints. Good luck KB |
|
From: Krzysztof B. <kb...@un...> - 2018-05-18 07:35:39
|
Hi Shiraz, W dniu 15.05.2018 o 11:11, Shiraz Memon pisze: > Hi Krzysztof, All, > > When an attribute is defined (under schema management) with the > minimum length equals 0 and set as mandatory in the registration form, > then unity should not let the user submit the registration form, if > the field is left empty by the user. Conversely another attribute is > defined with minimum length equals greater than 0 (e.g. 2) and set as > optional in the registration form, then the form should be > successfully submitted and accepted without any error dialogs/pop-ups. > In a nutshell, the registration forms should override the field > optionality defined in the schema management, what do you think? I think that the source of confusion is that we have two possible states: 0-length attribute value and no attribute value. In schema you can say that attribute with 0 length value is acceptable. But on UI - as registration - it is indistiguishable what was intended for empty cell: 0-length value or no value. We have ticket to fix it, most likely we will drop support for 0-length attribute values completely - what will simplify the situation, and the only control will be the optional or not setting on the form. Thanks, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2018-05-17 11:25:37
|
Dear Subscribers,
I'm happy to announce that 2.5.0 is available. The biggest changes are
around credentials supported by Unity.
When installing this release as an update a complex DB migration will be
performed and some configuration changes are necessary. Please make sure
to make a backup and read update instructions in the documentation. The
upgrade may be more difficult then usual but the amount of improvements
should make it worth the work.
Before enumerating the most important changes let me start from a big
thank you to D Baum for the German translation which was included in
this release./
/
The highlights are:
* A new *SMS credential* is now available. It can be used to login to
Unity by entering a code which was sent to a registered and
confirmed mobile telephone. The credential is integrated with all
Unity features: can be set up in registration forms, controlled on
HomeUI, used as first and second factor, etc.
* A new attribute type is now available: *verifiable mobile number*.
It is fully integrated with all standard Unity features. What is
more SMS credential can be bootstrapped using one of its values (if
present).
* *SMS code verification* is a new possibility when configuring
*password reset*.
* Password credential received a new configuration setting: *password
quality factor*. It can (and should!) take over the existing minimal
password length, minimal character classes and deny popular
sequences settings. The old ones are still supported and can be used
together with the new quality factor (although typically this should
not be necessary). The quality checking of a password is taking into
account many factors together. With this new setting Unity can
accept a complex but shorter password or a longer one which is using
only lowercase letters. Note that you can easily test the meaning of
the password settings directly from the password credential setup UI.
* *Password edit dialog* presented to users was redone. It now offers
a good UX, with instant feedback on password quality, fulfillment of
credential policies and additional suggestions how to improve the
passphrase.
* End-user oriented *credentials tab* in HomeUI, as well as all other
places where credentials are collected (e.g. the outdated credential
dialog), were greatly simplified, cleaned and should be much easier
to use.
* As mentioned above Unity contains now a *German translation*
* Up to now Unity triggered sending of *email confirmation messages*
automatically when a not confirmed email was added. Now it can be
controlled:
o For attributes created via registration forms there is a new
setting allowing admin to control when and if such attribute
should be confirmed: at request submission, acceptance, never or
perhaps attribute should be assumed to be confirmed. This new
option also allows for similar control of mobile phone verification.
o Admin user can now change confirmation status of attribute
without triggering the confirmation message being sent. If this
is desired the confirmation sending should be triggered manually.
* Users can now *resend* their *confirmation link* from HomeUI.
* *Message template *is now*bound to a channel* (sms or email). This
change simplifies configuration in other places (no channel setting
in registration forms), allows for creating templates specialized to
medium being used. As a side effect different channels can now be
used for various messages. For instance admin can receive SMS with
information on submitted registration request, while user is
notified with email about accepted or denied request.
Other, smaller changes:
* It is now possible to brand not only Unity web interfaces but also
error pages which are generated by Unity.
* Email identities are compared in a fully case insensitive way
* Older versions of MariaDB are now supported
* Password history checking was fixed and can be configured to be
fully disabled.
As always for more details see: http://www.unity-idm.eu/downloads/
Best regards,
Krzysztof
|
|
From: Sander A. <sa....@fz...> - 2018-05-16 12:51:12
|
Hi again,
and sorry for bothering you. I found the solution at another instance,
and I guess I had asked this in past.
The solution was
expression: attrObj['email'][0].getConfirmationInfo().isConfirmed()
Best regards,
Sander
Am Mittwoch, den 16.05.2018, 14:34 +0200 schrieb Sander Apweiler:
> Hi Krzysztof,
>
> I want to release the information whether email was confirmed to
> oauth
> clients. With unity 1.9.6 the rule below worked:
>
> condition: true
> action: createAttribute
> attributeName: email_verified
> expression: attr['mail'].confirmed
> mandatory: false
> attributeDisplayName: email validated
> attributeDescription: Was the email address confirmed?
>
> After the update to unity 2.4.2 it doesn't work anymore. I got the
> following error in log:
>
> 2018-05-16T14:27:49,883 [qtp1425617516-44] DEBUG
> unity.server.externaltranslation.OutputTranslationRule: [[TrProfile
> OauthOutputProfile], [r: 7]]Condition OK
> 2018-05-16T14:27:49,883 [qtp1425617516-44] ERROR
> unity.server.oauth.OAuthIdPEngine: Engine problem when handling
> client
> request
> org.mvel2.PropertyAccessException: [Error: could not access:
> confirmed;
> in class: java.util.HashMap]
> [Near : {... attr['mail'].confirmed ....}]
> ^
> [Line: 1, Column: 1]
>
> mail is an attribute from type verifiableEmail. Do you have any idea?
>
> 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 Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2018-05-16 12:34:58
|
Hi Krzysztof,
I want to release the information whether email was confirmed to oauth
clients. With unity 1.9.6 the rule below worked:
condition: true
action: createAttribute
attributeName: email_verified
expression: attr['mail'].confirmed
mandatory: false
attributeDisplayName: email validated
attributeDescription: Was the email address confirmed?
After the update to unity 2.4.2 it doesn't work anymore. I got the
following error in log:
2018-05-16T14:27:49,883 [qtp1425617516-44] DEBUG
unity.server.externaltranslation.OutputTranslationRule: [[TrProfile
OauthOutputProfile], [r: 7]]Condition OK
2018-05-16T14:27:49,883 [qtp1425617516-44] ERROR
unity.server.oauth.OAuthIdPEngine: Engine problem when handling client
request
org.mvel2.PropertyAccessException: [Error: could not access: confirmed;
in class: java.util.HashMap]
[Near : {... attr['mail'].confirmed ....}]
^
[Line: 1, Column: 1]
mail is an attribute from type verifiableEmail. Do you have any idea?
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 Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
----------------------------------------------------------------------- |
|
From: Shiraz M. <a....@fz...> - 2018-05-15 09:13:23
|
Hi Krzysztof, All, When an attribute is defined (under schema management) with the minimum length equals 0 and set as mandatory in the registration form, then unity should not let the user submit the registration form, if the field is left empty by the user. Conversely another attribute is defined with minimum length equals greater than 0 (e.g. 2) and set as optional in the registration form, then the form should be successfully submitted and accepted without any error dialogs/pop-ups. In a nutshell, the registration forms should override the field optionality defined in the schema management, what do you think? Cheers, Shiraz On Sun, May 13, 2018 at 8:34 PM Krzysztof Benedyczak <kb...@un...<mailto:kb...@un...>> wrote: Hi Shiraz, W dniu 09.05.2018 o 13:49, Shiraz Memon pisze: Hi, Unity (v2.4.2) is not accepting/submitting any registration form which has "optional" attributes of type string, BUT the minimum length is set to above zero (0) under schema management. Moreover the error which only appears on pop-up (not in the logs) is misleading as it does not say which "optional" attribute is suppose to be non-zero, if the multiple non-mandatory attributes are defined. "can not submit the registration request Value lenght(0) is too small, must be at least 2." Hmm - I can notice problem but only on acceptance (processing) of an already submitted request. Can you describe how you got the error upon submission? From your description it seems that you was able both to get this upon submission and when processing the request. A work around: Set minimum length of the non-mandatory/optional attributes of type string set to 0 under the schema management tab and ask the users to register again. I have not tested the inverse case: configure an attribute with minimum length to '0' but make it mandatory in the registration form Seems we will have to re-think support for 0-length values. It makes little sense in practice but lot of troubles as missing value and 0-length value are "hard" to distinguish. I've opened a ticket to cover this. Won't make it for the upcoming 2.5.0, but at least the error message upon accepting the request was improved so you get the name of the problematic attribute (and so you can ignore it). Cheers, Krzysztof -- Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ |
|
From: D B. <ba...@aw...> - 2018-05-14 09:45:01
|
Hi, On 09/05/18 23:46, Krzysztof Benedyczak wrote: > While looking at your attached log it seems that Unity receives an > unsigned request. Yeah, I'm just not sure what really happens because the Shibboleth logs kinda "claim" that signing happens: 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: signing the message 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: message encoded, sending redirect to client > I don't know details of your config - for > validRequester have you configured trusted URLs (unless you use metadata > to configure SLO)? You have an example at the very end of > http://www.unity-idm.eu/documentation/unity-2.4.0/saml-howto.html#_using_single_logout_slo I'm using metadata and Shibboleth has the following SingleLogoutServices configured: <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://shibboleth/Shibboleth.sso/SLO/SOAP"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://shibboleth/Shibboleth.sso/SLO/Redirect"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://shibboleth/Shibboleth.sso/SLO/POST"/> <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://shibboleth/Shibboleth.sso/SLO/Artifact"/> > Also one more hint: for redirect binding signing most likely won't be > performed by initiating side: request would be too large for encoding > into URL. I'm calling https://shibboleth/Shibboleth.sso/Logout, so Shibboleth is the initiating side (and it not signing would be consistent with the unity logs). So one solution would be to comment out the redirect binding in the Unity metadata used by Shibboleth, so that Shibboleth uses another binding to send the SLO request? Cheers, D. |
|
From: Krzysztof B. <kb...@un...> - 2018-05-13 18:34:24
|
Hi Shiraz, W dniu 09.05.2018 o 13:49, Shiraz Memon pisze: > Hi, > > Unity (v2.4.2) is not accepting/submitting any registration form which > has "optional" attributes of type string, BUT the minimum length is > set to above zero (0) under schema management. Moreover the error > which only appears on pop-up (not in the logs) is misleading as it > does not say which "optional" attribute is suppose to be non-zero, if > the multiple non-mandatory attributes are defined. > > "can not submit the registration request Value lenght(0) is too small, > must be at least 2." > Hmm - I can notice problem but only on acceptance (processing) of an already submitted request. Can you describe how you got the error upon submission? From your description it seems that you was able both to get this upon submission and when processing the request. > A work around: Set minimum length of the non-mandatory/optional > attributes of type string set to 0 under the schema management tab and > ask the users to register again. > > I have not tested the inverse case: configure an attribute with > minimum length to '0' but make it mandatory in the registration form Seems we will have to re-think support for 0-length values. It makes little sense in practice but lot of troubles as missing value and 0-length value are "hard" to distinguish. I've opened a ticket to cover this. Won't make it for the upcoming 2.5.0, but at least the error message upon accepting the request was improved so you get the name of the problematic attribute (and so you can ignore it). Cheers, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2018-05-09 21:46:42
|
Hi, W dniu 07.05.2018 o 19:09, D Baum pisze: > Hi, > > SSO works fine between my Unity IDP and Shibboleth SP now - but > unfortunately SAML Logout doesn't and I'm not even sure where the > problem comes from. > > If I set > unity.saml.spAcceptPolicy=validRequester > on the Unity IDP, it complains about unsigned LogoutRequests. Cut from > the attached log file: > eu.unicore.samly2.exceptions.SAMLRequesterException: SAML document is > not signed and the policy requires a signature > at > eu.unicore.samly2.validators.AbstractRequestValidator.validate(AbstractRequestValidator.java:87) > ~[samly2-2.3.3.jar:2.3.3] > > However, the Shibboleth SP is configured with > > <Logout signing="true" encryption="false">SAML2 Local</Logout> While looking at your attached log it seems that Unity receives an unsigned request. I don't know details of your config - for validRequester have you configured trusted URLs (unless you use metadata to configure SLO)? You have an example at the very end of http://www.unity-idm.eu/documentation/unity-2.4.0/saml-howto.html#_using_single_logout_slo Also one more hint: for redirect binding signing most likely won't be performed by initiating side: request would be too large for encoding into URL. HTH, KB |
|
From: Shiraz M. <a....@fz...> - 2018-05-09 11:50:26
|
Hi, Unity (v2.4.2) is not accepting/submitting any registration form which has "optional" attributes of type string, BUT the minimum length is set to above zero (0) under schema management. Moreover the error which only appears on pop-up (not in the logs) is misleading as it does not say which "optional" attribute is suppose to be non-zero, if the multiple non-mandatory attributes are defined. "can not submit the registration request Value lenght(0) is too small, must be at least 2." A work around: Set minimum length of the non-mandatory/optional attributes of type string set to 0 under the schema management tab and ask the users to register again. I have not tested the inverse case: configure an attribute with minimum length to '0' but make it mandatory in the registration form Cheers, Shiraz -- Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ |
|
From: D B. <ba...@aw...> - 2018-05-07 17:09:33
|
Hi, SSO works fine between my Unity IDP and Shibboleth SP now - but unfortunately SAML Logout doesn't and I'm not even sure where the problem comes from. If I set unity.saml.spAcceptPolicy=validRequester on the Unity IDP, it complains about unsigned LogoutRequests. Cut from the attached log file: eu.unicore.samly2.exceptions.SAMLRequesterException: SAML document is not signed and the policy requires a signature at eu.unicore.samly2.validators.AbstractRequestValidator.validate(AbstractRequestValidator.java:87) ~[samly2-2.3.3.jar:2.3.3] However, the Shibboleth SP is configured with <Logout signing="true" encryption="false">SAML2 Local</Logout> and says this in its shibd.log: 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: marshalled message: <samlp:LogoutRequest ...> 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: signing the message 2018-05-07 18:52:17 DEBUG OpenSAML.MessageEncoder.SAML2Redirect [5]: message encoded, sending redirect to client No signing error in the Shibboleth log... Finally, if I set unity.saml.spAcceptPolicy=all on Unity, logout works without errors. Shibboleth reports: Status of Global Logout: Logout completed successfully. Any hints on what's going wrong here or how I could figure out what's really going on? Cheers, D. |
|
From: Sander A. <sa....@fz...> - 2018-05-03 09:16:20
|
Hi Krzysztof,
yes the mixed rows was because of pasting the "old" content. New
condition seems to work. Thank you very much.
Best regards,
Sander
Am Donnerstag, den 03.05.2018, 09:53 +0200 schrieb Krzysztof
Benedyczak:
> Hi Sander,
>
> W dniu 02.05.2018 o 08:55, Sander Apweiler pisze:
> > Hi Krzysztof,
> >
> > I want to extract the organisation of users from
> > eduPersonScopedAffiliation (role@organisation) in input translation
> > rpofile, if this attribute is provided by remote IdP.
> >
> > At the moment my definition is:
> > condition: attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9'
> > action: mapAttribute
> > expression: attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].split("@")[1]
> >
> > It works fine if the IdP releases the correct attribute. But I got
> > the
> > first user with a malformed attribute. Is it possible to extend the
> > condition with a check if the attribute contains a @?
> >
> > Something like attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9'
> > action: mapAttribute &&
> > attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].contains('@') ?
>
> Yes - that's correct. I think you pasted the expression mixing rows
> with
> action, so to be sure something like this for the condition:
>
> attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9' &&
> attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].contains('@')
>
>
> 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 Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2018-05-03 07:55:49
|
W dniu 02.05.2018 o 13:40, Sander Apweiler pisze: > Hi Krzysztof, > > I have still a problem with refresh of IdPs. Unity refreshes the list > of IdPs once per hour but changes are not applied. E.g. DKFZ updates > their cert for signatures two weeks ago. I had to restart unity today > to enable login for users from DKFZ IdP. Before they got an error about > untrusted issuer. > > Deutsches Krebsforschungszentrum (DKFZ) Remote authentication failed. > Information for IT personnel: > The SAML response is either invalid or is issued by an untrusted > identity provider. > I think we have a generic problem with the endpoints which are in operation not catching up with runtime authenticator updates on some strange conditions. It was also reported for other then SAML authenticators, bug is already filled. Thanks KB |
|
From: Krzysztof B. <kb...@un...> - 2018-05-03 07:53:48
|
Hi Sander,
W dniu 02.05.2018 o 08:55, Sander Apweiler pisze:
> Hi Krzysztof,
>
> I want to extract the organisation of users from
> eduPersonScopedAffiliation (role@organisation) in input translation
> rpofile, if this attribute is provided by remote IdP.
>
> At the moment my definition is:
> condition: attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9'
> action: mapAttribute
> expression: attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].split("@")[1]
>
> It works fine if the IdP releases the correct attribute. But I got the
> first user with a malformed attribute. Is it possible to extend the
> condition with a check if the attribute contains a @?
>
> Something like attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9'
> action: mapAttribute &&
> attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].contains('@') ?
Yes - that's correct. I think you pasted the expression mixing rows with
action, so to be sure something like this for the condition:
attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9' &&
attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].contains('@')
Cheers
Krzysztof
|
|
From: Sander A. <sa....@fz...> - 2018-05-02 11:41:16
|
Hi Krzysztof, I have still a problem with refresh of IdPs. Unity refreshes the list of IdPs once per hour but changes are not applied. E.g. DKFZ updates their cert for signatures two weeks ago. I had to restart unity today to enable login for users from DKFZ IdP. Before they got an error about untrusted issuer. Deutsches Krebsforschungszentrum (DKFZ) Remote authentication failed. Information for IT personnel: The SAML response is either invalid or is issued by an untrusted identity provider. 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 Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2018-05-02 06:55:52
|
Hi Krzysztof,
I want to extract the organisation of users from
eduPersonScopedAffiliation (role@organisation) in input translation
rpofile, if this attribute is provided by remote IdP.
At the moment my definition is:
condition: attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9'
action: mapAttribute
expression: attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].split("@")[1]
It works fine if the IdP releases the correct attribute. But I got the
first user with a malformed attribute. Is it possible to extend the
condition with a check if the attribute contains a @?
Something like attr contains 'urn:oid:1.3.6.1.4.1.5923.1.1.1.9'
action: mapAttribute &&
attr['urn:oid:1.3.6.1.4.1.5923.1.1.1.9'].contains('@') ?
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 Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
-----------------------------------------------------------------------
----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2018-04-26 18:03:52
|
Hi, W dniu 25.04.2018 o 18:52, D Baum pisze: > Hi! > > On 24/04/18 00:05, Krzysztof Benedyczak wrote: >> Well probably this is bit misleading. The meaning of 0 means that no >> history should be checked previous passwords) but your new candidate for >> a password must be different from the current one still. Also I think >> (but I'd need to verify this) we may have a bug that reconfiguring >> credential to have lower limit (so changing the setting from say 10 to >> 1) in some cases won't work. This latter I need to confirm.> >> Anyway if you create a new credential with 0 then you won't be able to >> set a password to the current one. While this sounds nonsense I think we >> can still allow for this (assuming the setting is 0): to rehash the same >> password after password hashing configuration change. > Not quite sure I understand. Is there a difference between setting > history of 0 and 1 then? Does 1 mean "not the last one and the one > before that"? So the current one (which you call last one I think) is always checked and the config number tells how many additional should be checked. >> Have you changed your authenticator configuration to use the >> 'SimplePassword' instead of sys:password? > Ah, that's the trick! Thanks! > > One thing I'm not sure about yet is: Do I need to manually reset the > passwords for the users (as admin) so that they are able to log in when > the new password restrictions are applied? (I got that impression but > I'm not sure.) > > If so, how do I update the admin password without locking myself out of > the admin account? There is huge difference between updating credential settings and changing the credential. In the first case you basically have to do nothing special: if you change configuration of the password that some existing passwords do not conform, those will be treated as outdated on the first subseqent use (and user will have to change the password). If you however want to start using a new password credential (e.g. used fooPass, now using barPass) you just need to make sure that your users have this password. >> Actually we hit this couple of times too. We are thinking how to enable >> such feature without creating super-complex credential config and at the >> same time being able to provide sensible user experience and control. > Yeah, if the user only gets "Password too weak" they have no indication > what it takes to make the password stronger. > Maybe a progress bar above/below the password field that fills up as > more "password strength" gets added to the password? yes, and more :-) Thanks, Krzysztof |
|
From: D B. <ba...@aw...> - 2018-04-25 16:52:30
|
Hi!
On 24/04/18 00:05, Krzysztof Benedyczak wrote:
> Well probably this is bit misleading. The meaning of 0 means that no
> history should be checked previous passwords) but your new candidate for
> a password must be different from the current one still. Also I think
> (but I'd need to verify this) we may have a bug that reconfiguring
> credential to have lower limit (so changing the setting from say 10 to
> 1) in some cases won't work. This latter I need to confirm.>
> Anyway if you create a new credential with 0 then you won't be able to
> set a password to the current one. While this sounds nonsense I think we
> can still allow for this (assuming the setting is 0): to rehash the same
> password after password hashing configuration change.
Not quite sure I understand. Is there a difference between setting
history of 0 and 1 then? Does 1 mean "not the last one and the one
before that"?
> Have you changed your authenticator configuration to use the
> 'SimplePassword' instead of sys:password?
Ah, that's the trick! Thanks!
One thing I'm not sure about yet is: Do I need to manually reset the
passwords for the users (as admin) so that they are able to log in when
the new password restrictions are applied? (I got that impression but
I'm not sure.)
If so, how do I update the admin password without locking myself out of
the admin account?
> Actually we hit this couple of times too. We are thinking how to enable
> such feature without creating super-complex credential config and at the
> same time being able to provide sensible user experience and control.
Yeah, if the user only gets "Password too weak" they have no indication
what it takes to make the password stronger.
Maybe a progress bar above/below the password field that fills up as
more "password strength" gets added to the password?
> I
> even think this can go into next release as we are anyway working on
> making password setting/reset/update user friendly (better UI, feedback)
> for 2.5.
Sounds great!
> Having this defined as "minimum allowed security index" is somewhat
> difficult as admins typically won't know what is a "strong" or "low"
> index. But maybe it is the way to go. I've checked keepass and indeed it
> seems to use dictionary ('alic' has higher score then 'alice'), but this
> is pretty poor dictionary
And also the dictionary would/could depend on the language.
> Thinking in progress - feature request of course accepted.
Thanks!
Best,
D.
|
|
From: D B. <ba...@aw...> - 2018-04-24 16:47:59
|
Hi! On 23/04/18 23:41, Krzysztof Benedyczak wrote: > Sorry - I should have noticed this earlier. You wrote that you are using > 2.4.1 - it contained bug UY-684 which was fixed in 2.4.2 - and it is > precisely what you are observing. So please update to the latest version. Fix confirmed, thank you! :-) And: sorry - I should have checked the issue tracker and worked on the latest version... I hope next time I'll do better :-) Best, D. |
