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
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Shiraz M. <a....@fz...> - 2018-12-18 12:03:42
|
I guess the following snapshot is related too [image.png] On Tue, Dec 18, 2018 at 12:42 PM Shiraz Memon <a....@fz...<mailto:a....@fz...>> wrote: Hi, I am not able to create a database dump file. [image.png] Cheers, Shiraz On Fri, Dec 14, 2018 at 12:12 AM Krzysztof Benedyczak <kb...@un...<mailto:kb...@un...>> wrote: Shiraz, W dniu 13.12.2018 o 10:18, Shiraz Memon pisze: > Hi Krzysztof, All, > > After upgrading from 2.4.2 to 2.7.3, as an admin i cannot view the > registration requests, any clues? > That's a bug, I've just checked that we are missing one migration in 2.7.0 in one rather rare case. So this is not related to skipping updates as Sander suggested, rather that you have some special historical registration requests. As this is too late to fix the migration code we will need to create a patch for runtime handling of this discrepancy and align the data in 2.8.0 migration. If you want a quick workaround you can fix the JSON dump and import it again (or export, fix and import). The change in JSON dump would be to change all occurrences of the string "afterRemoteLogin" to "afterRemoteLoginWhenUnknownUser" (including ""). Fix will be in 2.7.4. Krzysztof -- Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 -- 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: Shiraz M. <a....@fz...> - 2018-12-18 11:43:42
|
Hi, I am not able to create a database dump file. [image.png] Cheers, Shiraz On Fri, Dec 14, 2018 at 12:12 AM Krzysztof Benedyczak <kb...@un...<mailto:kb...@un...>> wrote: Shiraz, W dniu 13.12.2018 o 10:18, Shiraz Memon pisze: > Hi Krzysztof, All, > > After upgrading from 2.4.2 to 2.7.3, as an admin i cannot view the > registration requests, any clues? > That's a bug, I've just checked that we are missing one migration in 2.7.0 in one rather rare case. So this is not related to skipping updates as Sander suggested, rather that you have some special historical registration requests. As this is too late to fix the migration code we will need to create a patch for runtime handling of this discrepancy and align the data in 2.8.0 migration. If you want a quick workaround you can fix the JSON dump and import it again (or export, fix and import). The change in JSON dump would be to change all occurrences of the string "afterRemoteLogin" to "afterRemoteLoginWhenUnknownUser" (including ""). Fix will be in 2.7.4. 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: Krzysztof B. <kb...@un...> - 2018-12-17 20:00:28
|
Hi Willem, W dniu 17.12.2018 o 10:53, Willem Elbers pisze: > Hi Krzysztof, > > thanks for the reply. Your suggestion in point 2 was the solution for > our issue. > > Our restore procedure is now the following: > 1. start a fresh instance of unity 2.4.2 or 2.6.0 with all > authenticators using "sys:password" credential > 2. restore database backup > 3. update all authenticators to use the "Password credential" credential > > Our main goal was to test the ldapEndpoint in the 2.6.x release. Now > having to invalidate all users password is a big plus when updating > our production instance so I will also have a look at porting the ldap > endpoint to the 2.7.x branch. Anything I should be aware of when doing > this? > I assume you wanted to write "Now NOT having to invalidate...". This improvement was added in 2.7.3. You should be aware of everything that upgrade docs say when migrating from 2.6 to 2.7 (as you can see not many potentially problematic changes). Some of the changes can require updates of custom CSSes, if you have them very much self-crafted. We are working on a 100% bugfix release 2.7.4, it will be out this still year. But update to 2.7.4 should just plain simple. Best, Krzysztof |
|
From: Willem E. <wi...@cl...> - 2018-12-17 09:53:37
|
Hi Krzysztof,
thanks for the reply. Your suggestion in point 2 was the solution for our
issue.
Our restore procedure is now the following:
1. start a fresh instance of unity 2.4.2 or 2.6.0 with all authenticators
using "sys:password" credential
2. restore database backup
3. update all authenticators to use the "Password credential" credential
Our main goal was to test the ldapEndpoint in the 2.6.x release. Now having
to invalidate all users password is a big plus when updating our production
instance so I will also have a look at porting the ldap endpoint to the
2.7.x branch. Anything I should be aware of when doing this?
Best,
Willem
On Tue, Dec 11, 2018 at 9:13 PM Krzysztof Benedyczak <kb...@un...>
wrote:
> Hi Willem,
>
>
> W dniu 11.12.2018 o 13:59, Willem Elbers pisze:
> > Hi Krzysztof,
> >
> > we are trying to upgrade our unity instance to a recent 2.x version
> > (2.6.x preferably).
> >
> > The upgrade from 1.9.6 to 2.0.0 seems to go fine, but then upgrading
> > to 2.4.0 or anything higher results in users without password. As far
> > as I can see in section 4.2.4 of the upgrade documentation there is no
> > specific action required with respect to existing password, even
> > though a new sys:password credential has been introduced. I've also
> > noticed that on a fresh 2.4.0 test installation our admin user is
> > requested to update the credential because of the credential
> requirements.
> >
> > In our 1.9.6 installation we are using a custom password credential,
> > but this is included in the database export:
> >
> Yes, this should in general work, thought it is a huge jump, over
> something like 2 years, so hard to make bold statements.
>
> Some hints how to investigate the issue:
>
> 1. I'd try to configure the default admin user (admin2x or something
> like this with some password in unityServer.conf) + change your web
> authenticator used by admin endpoint to use sys:password credential.
> This temporal change should allow you to login to adminUI, so that you
> can more easily inspect what is really set (or is not) for your users.
> For each user you can see the internal attribute storing password (check
> 'internal' attributes in attributes panel), also credential details will
> show details of credentials.
>
> After getting into admin UI you may check the credential definitions, do
> JSON export and check if it is all right.
>
> 2. Different path (maybe the most promising?): It may happen that
> credentials are all right, but your admin endpoint or its authenticator
> configuration was not migrated properly (or even was but is overwritten
> by your new config from file). Make sure that your endpoint is using the
> proper password credential ("Password credential" literal), not for
> instance sys:password, which obviously was not defined in 1.9 but is a
> default now. For this case you would also get errors like you got.
>
> 3. Have you carefully checked migration logs? Any issues there?
>
>
> BTW: I'd strongly encourage you to go with the latest version. 2.7.3
> introduced a feature that will help you a lot: passwords stored with
> legacy hashing mechanism used in 1.9 can be rehashed automatically,
> without a need for a user to reset it.
>
>
> HTH,
>
> Krzysztof
>
>
|
|
From: Krzysztof B. <kb...@un...> - 2018-12-13 23:12:19
|
Shiraz, W dniu 13.12.2018 o 10:18, Shiraz Memon pisze: > Hi Krzysztof, All, > > After upgrading from 2.4.2 to 2.7.3, as an admin i cannot view the > registration requests, any clues? > That's a bug, I've just checked that we are missing one migration in 2.7.0 in one rather rare case. So this is not related to skipping updates as Sander suggested, rather that you have some special historical registration requests. As this is too late to fix the migration code we will need to create a patch for runtime handling of this discrepancy and align the data in 2.8.0 migration. If you want a quick workaround you can fix the JSON dump and import it again (or export, fix and import). The change in JSON dump would be to change all occurrences of the string "afterRemoteLogin" to "afterRemoteLoginWhenUnknownUser" (including ""). Fix will be in 2.7.4. Krzysztof |
|
From: Sander A. <sa....@fz...> - 2018-12-13 12:40:42
|
Hi Krzysztof, hi Shiraz, it seems that this issue only occurs if you skip some releases. After Update from 2.7.2 to 2.7.3 I still see the requests. Best regards, Sander On Thu, 2018-12-13 at 10:18 +0100, Shiraz Memon wrote: > Hi Krzysztof, All, > > After upgrading from 2.4.2 to 2.7.3, as an admin i cannot view the > registration requests, any clues? > > > Thanks, > Shiraz > _______________________________________________ > 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 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-12-13 09:19:22
|
Hi Krzysztof, All, After upgrading from 2.4.2 to 2.7.3, as an admin i cannot view the registration requests, any clues? [image.png] Thanks, 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: Krzysztof B. <kb...@un...> - 2018-12-11 20:16:11
|
Hi, It seems that you get an error from upstream (SAML) IdP. Perhaps it does not trust your new instance? Try to enable TRACE logging on SAML. You will see the response contents that you get (also SAML request that unity sends to the IdP), this should shed some light on the details. Cheers, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2018-12-11 20:12:29
|
Hi Willem,
W dniu 11.12.2018 o 13:59, Willem Elbers pisze:
> Hi Krzysztof,
>
> we are trying to upgrade our unity instance to a recent 2.x version
> (2.6.x preferably).
>
> The upgrade from 1.9.6 to 2.0.0 seems to go fine, but then upgrading
> to 2.4.0 or anything higher results in users without password. As far
> as I can see in section 4.2.4 of the upgrade documentation there is no
> specific action required with respect to existing password, even
> though a new sys:password credential has been introduced. I've also
> noticed that on a fresh 2.4.0 test installation our admin user is
> requested to update the credential because of the credential requirements.
>
> In our 1.9.6 installation we are using a custom password credential,
> but this is included in the database export:
>
Yes, this should in general work, thought it is a huge jump, over
something like 2 years, so hard to make bold statements.
Some hints how to investigate the issue:
1. I'd try to configure the default admin user (admin2x or something
like this with some password in unityServer.conf) + change your web
authenticator used by admin endpoint to use sys:password credential.
This temporal change should allow you to login to adminUI, so that you
can more easily inspect what is really set (or is not) for your users.
For each user you can see the internal attribute storing password (check
'internal' attributes in attributes panel), also credential details will
show details of credentials.
After getting into admin UI you may check the credential definitions, do
JSON export and check if it is all right.
2. Different path (maybe the most promising?): It may happen that
credentials are all right, but your admin endpoint or its authenticator
configuration was not migrated properly (or even was but is overwritten
by your new config from file). Make sure that your endpoint is using the
proper password credential ("Password credential" literal), not for
instance sys:password, which obviously was not defined in 1.9 but is a
default now. For this case you would also get errors like you got.
3. Have you carefully checked migration logs? Any issues there?
BTW: I'd strongly encourage you to go with the latest version. 2.7.3
introduced a feature that will help you a lot: passwords stored with
legacy hashing mechanism used in 1.9 can be rehashed automatically,
without a need for a user to reset it.
HTH,
Krzysztof
|
|
From: Krzysztof B. <kb...@un...> - 2018-12-11 19:57:49
|
Hi Sander, W dniu 10.12.2018 o 07:38, Sander Apweiler pisze: > Hi Krzyzstof, > > we are releasing the entitlement of users as an oauth scope. If the > attribute is multivalued, unity release it as list but if it is single > valued, units releases it as string. Our output translation profile > confiog for this attribute is below. Is there a way to release even > single valued attributes as list of attributes, containing one value? > > Condition: attr contains 'eduPersonEntitlement' > Action: CreateAttribute > attribute name: eduperson_entitlement > expression: attrs['eduPersonEntitlement'] > mandatory: no > attribute displayname: eduPersonEntitlement > attribute description: Group membership expression I was thinking about this and... no idea how to neatly solve this. Profile always produces a list of values for an attribute. Serialization of this to JSON uses a simple logic: if attribute is single-valued then just output it, otherwise output it as a list of values. I think this is a very legitimate use case. But to solve this completely we should have some way to annotate non default serialization to JSON details. Actually not only for attributes created by output profile: for the regular ones we have the same story. Seems as a feature request. Best KB |
|
From: Alvaro A. <alv...@tu...> - 2018-12-11 14:36:37
|
Hello, I'm trying to set up an OAuth 2 endpoint with a SAML authenticator (DFN AAI). Half of the authentication process seems to be working: I get forwarded to Unity (2.7.2) and see all the IdP's. Unfortunately I get an error after entering my credentials. According to the log file there is no assertion found in the SAML response. Does any one has an idea how to go about this problem? 2018-12-11T14:30:50,126 [qtp1177522153-91] DEBUG unity.server.saml.SAMLRetrievalUI: Starting remote SAML authn, current relative URI is /oauth2-as/oauth2-authz-web-entry 2018-12-11T14:30:50,240 [qtp1177522153-93] DEBUG unity.server.saml.RedirectRequestHandler: Starting SAML HTTP Redirect binding exchange with IdP https://idp2.tu-dresden.de/idp/profile/SAML2/Redirect/SSO 2018-12-11T14:30:52,410 [qtp1177522153-93] DEBUG unity.server.saml.SamlHttpServlet: Got SAML response using the HTTP POST binding 2018-12-11T14:30:52,670 [qtp1177522153-91] WARN unity.server.saml.SAMLRetrievalUI: SAML response verification or processing failed pl.edu.icm.unity.engine.api.authn.AuthenticationException: The SAML response is either invalid or is issued by an untrusted identity provider. at pl.edu.icm.unity.saml.SAMLResponseValidatorUtil.verifySAMLResponse(SAMLResponseValidatorUtil.java:88) ~[unity-server-saml-2.7.2.jar:?] at pl.edu.icm.unity.saml.sp.SAMLVerificator.getRemotelyAuthenticatedInput(SAMLVerificator.java:312) ~[unity-server-saml-2.7.2.jar:?] at pl.edu.icm.unity.saml.sp.SAMLVerificator.verifySAMLResponse(SAMLVerificator.java:283) ~[unity-server-saml-2.7.2.jar:?] at pl.edu.icm.unity.saml.sp.web.SAMLRetrievalUI.onSamlAnswer(SAMLRetrievalUI.java:213) [unity-server-saml-2.7.2.jar:?] at pl.edu.icm.unity.saml.sp.web.SAMLRetrievalUI.refresh(SAMLRetrievalUI.java:275) [unity-server-saml-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.column.AuthNPanelBase.refresh(AuthNPanelBase.java:35) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.column.ColumnInstantAuthenticationScreen.refreshAuthenticationState(ColumnInstantAuthenticationScreen.java:320) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.column.ColumnInstantAuthenticationScreen.refresh(ColumnInstantAuthenticationScreen.java:123) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.AuthenticationUI.refresh(AuthenticationUI.java:257) [unity-server-web-common-2.7.2.jar:?] at com.vaadin.ui.UI.doRefresh(UI.java:861) [vaadin-server-8.5.2.jar:8.5.2] at com.vaadin.server.communication.UIInitHandler.reinitUI(UIInitHandler.java:269) [vaadin-server-8.5.2.jar:8.5.2] at com.vaadin.server.communication.UIInitHandler.getBrowserDetailsUI(UIInitHandler.java:171) [vaadin-server-8.5.2.jar:8.5.2] at com.vaadin.server.communication.UIInitHandler.synchronizedHandleRequest(UIInitHandler.java:76) [vaadin-server-8.5.2.jar:8.5.2] at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) [vaadin-server-8.5.2.jar:8.5.2] at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1601) [vaadin-server-8.5.2.jar:8.5.2] at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:445) [vaadin-server-8.5.2.jar:8.5.2] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [javax.servlet-api-3.1.0.jar:3.1.0] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1655) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at pl.edu.icm.unity.webui.authn.InvocationContextSetupFilter.doFilter(InvocationContextSetupFilter.java:77) [unity-server-web-common-2.7.2.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at pl.edu.icm.unity.webui.authn.ProxyAuthenticationFilter.doFilter(ProxyAuthenticationFilter.java:122) [unity-server-web-common-2.7.2.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at pl.edu.icm.unity.webui.authn.AuthenticationFilter.gotoNotProtectedResource(AuthenticationFilter.java:260) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.AuthenticationFilter.handleNotProtectedResource(AuthenticationFilter.java:103) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.AuthenticationFilter.doFilter(AuthenticationFilter.java:80) [unity-server-web-common-2.7.2.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:203) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:73) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at pl.edu.icm.unity.webui.authn.AuthenticationFilter.forwardtoAuthn(AuthenticationFilter.java:232) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.AuthenticationFilter.handleRememberMe(AuthenticationFilter.java:206) [unity-server-web-common-2.7.2.jar:?] at pl.edu.icm.unity.webui.authn.AuthenticationFilter.doFilter(AuthenticationFilter.java:84) [unity-server-web-common-2.7.2.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at pl.edu.icm.unity.engine.api.utils.HiddenResourcesFilter.doFilter(HiddenResourcesFilter.java:49) [unity-server-engine-api-2.7.2.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at pl.edu.icm.unity.oauth.as.webauthz.OAuthGuardFilter.doFilterInterruptible(OAuthGuardFilter.java:91) [unity-server-oauth-2.7.2.jar:?] at pl.edu.icm.unity.oauth.as.webauthz.OAuthGuardFilter.doFilter(OAuthGuardFilter.java:52) [unity-server-oauth-2.7.2.jar:?] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1642) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1340) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) [jetty-servlet-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1242) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) [jetty-rewrite-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:690) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.Server.handle(Server.java:503) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [jetty-server-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [jetty-io-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) [jetty-util-9.4.12.v20180830.jar:9.4.12.v20180830] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] Caused by: eu.unicore.samly2.exceptions.SAMLValidationException: There was no authentication assertion found in the SAML response at eu.unicore.samly2.validators.SSOAuthnResponseValidator.validate(SSOAuthnResponseValidator.java:128) ~[samly2-2.3.3.jar:2.3.3] at pl.edu.icm.unity.saml.SAMLResponseValidatorUtil.verifySAMLResponse(SAMLResponseValidatorUtil.java:85) ~[unity-server-saml-2.7.2.jar:?] ... 82 more Kind regards, Alvaro -- Dipl.-Inf. Alvaro Aguilera Wissenschaftlicher Mitarbeiter Technische Universität Dresden Zentrum für Informationsdienste und Hochleistungsrechnen Verteiltes und Datenintensives Rechnen Büro: Falkenbrunnen, Raum 242 Chemnitzer Straße 46b 01187 Dresden Tel: +49 (351) 463 33491 Email: alv...@tu... Web: http://www.tu-dresden.de/zih OTR-Fingerprint: 9CD3BC97 ACFB7430 D084BA9D 4BEB1775 4B0BA9F1 |
|
From: Willem E. <wi...@cl...> - 2018-12-11 13:17:49
|
Hi Krzysztof,
we are trying to upgrade our unity instance to a recent 2.x version (2.6.x
preferably).
The upgrade from 1.9.6 to 2.0.0 seems to go fine, but then upgrading to
2.4.0 or anything higher results in users without password. As far as I can
see in section 4.2.4 of the upgrade documentation there is no specific
action required with respect to existing password, even though a new
sys:password credential has been introduced. I've also noticed that on a
fresh 2.4.0 test installation our admin user is requested to update the
credential because of the credential requirements.
In our 1.9.6 installation we are using a custom password credential, but
this is included in the database export:
...
{
"id" : 10,
"name" : "sys:Credential:Password credential",
"contents" : {
"flags" : 3,
"maxElements" : 1,
"minElements" : 1,
"selfModificable" : false,
"uniqueValues" : false,
"visibility" : "local",
"syntaxState" :
"{\"regexp\":\"\",\"minLength\":0,\"maxLength\":10240}",
"displayedName" : {
"DefaultValue" : "sys:Credential:Password credential",
"Map" : { }
},
"i18nDescription" : {
"DefaultValue" : null,
"Map" : {
"en" : "Credential of Password credential"
}
},
"metadata" : { }
},
"valueSyntaxId" : "string"
}
...
With the log level on debug there is no clear indication of any issue
during the database restore or server startup. I assume this credential
definition gets imported as well. Is that correct?
When trying to log in we get the following error:
DEBUG unity.server.PasswordVerificator: The user has no password set: admin
DEBUG unity.server.PasswordVerificator: The user has no password set:
te...@cl...
Any idea what could be the issue here and how we can solve this?
Best,
Willem
|
|
From: Sander A. <sa....@fz...> - 2018-12-10 06:38:21
|
Hi Krzyzstof, we are releasing the entitlement of users as an oauth scope. If the attribute is multivalued, unity release it as list but if it is single valued, units releases it as string. Our output translation profile confiog for this attribute is below. Is there a way to release even single valued attributes as list of attributes, containing one value? Condition: attr contains 'eduPersonEntitlement' Action: CreateAttribute attribute name: eduperson_entitlement expression: attrs['eduPersonEntitlement'] mandatory: no attribute displayname: eduPersonEntitlement attribute description: Group membership expression 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-12-09 15:05:44
|
Hi Sander, W dniu 06.12.2018 o 15:46, Sander Apweiler pisze: > Hi Krzysztof, > > we are running unity 2.4.2 and if a SP uses SLO with HTTP Redirect we > got an error about missing signature. The SP signs the logout request. > > Is there some additional configuration needed? It is hard to tell, not even knowing which actor shows error. In general I'd say that using HTTP redirect + SAML signatures is very unreliable, in many cases even not supported and typically shouldn't be used. In HTTP redirect world your SAML message is encoded as URL parameter. Those are limited in size and so if the request is signed, the URL might be simply too long (for everything that handles it: starting from browser via HTTP server on Unity ending). Cheers, KB |
|
From: Sander A. <sa....@fz...> - 2018-12-06 14:47:52
|
Hi Krzysztof, we are running unity 2.4.2 and if a SP uses SLO with HTTP Redirect we got an error about missing signature. The SP signs the logout request. Is there some additional configuration needed? 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-12-06 11:30:50
|
Hi Shiraz, W dniu 05.12.2018 o 12:01, Shiraz Memon pisze: > Hi Krzysztof, > > Is it possible to somehow restrict which scopes the oidc clients can > request from unity (as the oidc authz server)? > No, every client can request any scopes, and it is up to user to decide whether he or she allows for them (with all or nothing). Cheers, KB |
|
From: Shiraz M. <a....@fz...> - 2018-12-05 11:03:17
|
Hi Krzysztof, Is it possible to somehow restrict which scopes the oidc clients can request from unity (as the oidc authz server)? Thanks, 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: Krzysztof B. <kb...@un...> - 2018-12-01 22:11:44
|
Dear Subscribers,
The next release – *2.7.3* – is out. It includes numerous small to
medium improvements and one important bugfix.
The most significant changes are:
* Registration form can be configured now to automatically login a
user who submitted a registration request and the request was
auto-accepted. (Won’t work if user has to confirm her email first).
* Couple of password related improvements were added:
o Password reset is not required anymore after changing password
storage/hashing parameters. Instead a password is rehashed on
the fly when user is being signed in for the first time after
configuration change.
o Identities grid in AdminUI allows now for showing a detailed
information on all credential statuses.
o When editing password quality settings, admin can verify with
one click whether the setting is secure and how it will affect
sign in time.
* Forgotten password reset UI was refactored not to use popup dialogs.
This the last step of aligning UX of the authN screen: all sign in,
registration, outdated password and forgotten password UIs are using
the same full screen, clean approach, which is simpler to use and
easier to brand.
* Session expiration handling was improved. The older method was not
perfect, e.g. session inactivity timeouts were enforced with +/- 20s
tolerance. Current implementation should be precise and more solid.
* A bug which was causing some of the dynamic attributes not to be
returned was fixed. This affected a single REST API resource
(resolving of complete group contents) and custom attribute columns
in Admin UI Identities grid.
Complete list of changes is available on the
http://www.unity-idm.eu/downloads/ page.
Best regards,
Krzysztof
|
|
From: Sander A. <sa....@fz...> - 2018-11-26 09:02:40
|
Hi Krzysztof,
thanks a lot. Removing the logout:true has solved the issue.
Best regards,
Sander
On Sat, 2018-11-24 at 10:57 +0100, Krzysztof Benedyczak wrote:
> Hi,
>
> W dniu 23.11.2018 o 14:04, Sander Apweiler pisze:
> > Hi Krzysztof,
> >
> > We try to use the token revocation mechanism. If we user user_id,
> > we
> > get an error about missing client_id. "Invalid request; To access
> > the
> > token revocation endpoint a client_id must be provided". It seems
> > that
> > there is a mistake in the example from manual.
> >
> > If we provide client_id, we get an error about missing token type:
> > "Invalid request; To access the token revocation endpoint a token
> > type
> > must be provided". Can you please add this necessary parameter in
> > the
> > manual?
>
> Sure, thanks for info. This chapter was not updated after revocation
> of
> refresh tokens was implemented. Updated version will be published
> soon
> with 2.7.3, including the fix of the user_id mistake in example.
>
>
> > If we provide the token type, we end up in a invalid scope
> > error: " Retuning OAuth error response: invalid_scope: Invalid,
> > unknown
> > or
> > malformed scope; Insufficent scope to perform full logout." Do we
> > need
> > to enable the token revocation scope in unity explicit? How does
> > the
> > valid request looks like?
> >
> > We request the scopes profile email and single-logout.
> > The parameters we send in revocation request:
> >
> > r = requests.post(auth_server + "/oauth2/revoke",
> > headers={ 'Content-Type': 'application/x-www-form-
> > urlencoded'},
> > data={ 'token': auth_state['access_token'],
> > 'client_id': CLIENT_ID,
> > 'token_type_hint': 'access_token',
> > 'token_type': 'Bearer',
> > 'logout': 'true', }
> > )
> >
> > auth_state['access_token'] contains the bearer token and CLIENT_ID
> > the
> > client id.
>
> Actually this part is covered in the manual correctly - but I
> understnd
> that you gave up after coming over two mistakes :-)
>
> Besides the standard token revocation, it is also possible to
> request
> token's owner logout (disposal of the SSO session)together with
> token
> revocation. To be able to perform this operation, the client must
> request and obtain a special OAuth scope: +single-logout+. Having
> this
> scope, token revocation can be used to logout the token owner
> by adding the following form parameter to the request: +logout=true+.
>
> So either remove logout: true from your request or define and
> request
> the single-logout OAuth scope - i.e. scope with exactly this name
> must
> be bound to the access token.
>
> Cheers,
> 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 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-11-24 09:56:51
|
Hi,
W dniu 23.11.2018 o 14:04, Sander Apweiler pisze:
> Hi Krzysztof,
>
> We try to use the token revocation mechanism. If we user user_id, we
> get an error about missing client_id. "Invalid request; To access the
> token revocation endpoint a client_id must be provided". It seems that
> there is a mistake in the example from manual.
>
> If we provide client_id, we get an error about missing token type:
> "Invalid request; To access the token revocation endpoint a token type
> must be provided". Can you please add this necessary parameter in the
> manual?
Sure, thanks for info. This chapter was not updated after revocation of
refresh tokens was implemented. Updated version will be published soon
with 2.7.3, including the fix of the user_id mistake in example.
> If we provide the token type, we end up in a invalid scope
> error: " Retuning OAuth error response: invalid_scope: Invalid, unknown
> or
> malformed scope; Insufficent scope to perform full logout." Do we need
> to enable the token revocation scope in unity explicit? How does the
> valid request looks like?
>
> We request the scopes profile email and single-logout.
> The parameters we send in revocation request:
>
> r = requests.post(auth_server + "/oauth2/revoke",
> headers={ 'Content-Type': 'application/x-www-form-urlencoded'},
> data={ 'token': auth_state['access_token'],
> 'client_id': CLIENT_ID,
> 'token_type_hint': 'access_token',
> 'token_type': 'Bearer',
> 'logout': 'true', }
> )
>
> auth_state['access_token'] contains the bearer token and CLIENT_ID the
> client id.
Actually this part is covered in the manual correctly - but I understnd
that you gave up after coming over two mistakes :-)
Besides the standard token revocation, it is also possible to request
token's owner logout (disposal of the SSO session)together with token
revocation. To be able to perform this operation, the client must
request and obtain a special OAuth scope: +single-logout+. Having this
scope, token revocation can be used to logout the token owner
by adding the following form parameter to the request: +logout=true+.
So either remove logout: true from your request or define and request
the single-logout OAuth scope - i.e. scope with exactly this name must
be bound to the access token.
Cheers,
KB
|
|
From: Sander A. <sa....@fz...> - 2018-11-23 13:05:11
|
Hi Krzysztof,
We try to use the token revocation mechanism. If we user user_id, we
get an error about missing client_id. "Invalid request; To access the
token revocation endpoint a client_id must be provided". It seems that
there is a mistake in the example from manual.
If we provide client_id, we get an error about missing token type:
"Invalid request; To access the token revocation endpoint a token type
must be provided". Can you please add this necessary parameter in the
manual?
If we provide the token type, we end up in a invalid scope
error: " Retuning OAuth error response: invalid_scope: Invalid, unknown
or
malformed scope; Insufficent scope to perform full logout." Do we need
to enable the token revocation scope in unity explicit? How does the
valid request looks like?
We request the scopes profile email and single-logout.
The parameters we send in revocation request:
r = requests.post(auth_server + "/oauth2/revoke",
headers={ 'Content-Type': 'application/x-www-form-urlencoded'},
data={ 'token': auth_state['access_token'],
'client_id': CLIENT_ID,
'token_type_hint': 'access_token',
'token_type': 'Bearer',
'logout': 'true', }
)
auth_state['access_token'] contains the bearer token and CLIENT_ID the
client id.
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-11-18 18:40:36
|
Hi, W dniu 16.11.2018 o 13:39, Sander Apweiler pisze: > Hi Krzysztof, > > On Fri, 2018-11-16 at 10:53 +0100, Krzysztof Benedyczak wrote: >> Hi Sander, >> >> W dniu 15.11.2018 o 14:31, Sander Apweiler pisze: >>> Hi Krzysztof, >>> >>> at the moment I'm testing unity 2.7.2. I have enabled different >>> kind of >>> authenticators, one of the are local accounts with username >>> password. I >>> have enabled the user registration on userhome too (see >>> userhome.properties config below), but the link "Register a new >>> account" from previous versions is not available on the userhome. >>> Is >>> this behaviour intended? >>> >> And do you have a *public* registration form defined? Also it would >> be a >> good practice to enumerate on the home endpoint which of the public >> forms should be enabled there. > Yes I have three public registration forms (oauth client, username > password and certificate). If I use the URL in the browser, I get the > form. But the link "Register a new account" on endpoint is missing. ah, sorry, forgot about one thing. Now there are two ways to show registration links: either in header as before or among sign-in options as button. To enable the former you need to set: unity.endpoint.web.showRegistrationFormsInHeader=true I'll change the default to true so it is less confusing. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2018-11-16 12:40:41
|
Hi Krzysztof, On Fri, 2018-11-16 at 10:53 +0100, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 15.11.2018 o 14:31, Sander Apweiler pisze: > > Hi Krzysztof, > > > > at the moment I'm testing unity 2.7.2. I have enabled different > > kind of > > authenticators, one of the are local accounts with username > > password. I > > have enabled the user registration on userhome too (see > > userhome.properties config below), but the link "Register a new > > account" from previous versions is not available on the userhome. > > Is > > this behaviour intended? > > > > And do you have a *public* registration form defined? Also it would > be a > good practice to enumerate on the home endpoint which of the public > forms should be enabled there. Yes I have three public registration forms (oauth client, username password and certificate). If I use the URL in the browser, I get the form. But the link "Register a new account" on endpoint is missing. Cheers, Sander > > > Cheers, > 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 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-11-16 09:53:16
|
Hi Sander, W dniu 15.11.2018 o 14:31, Sander Apweiler pisze: > Hi Krzysztof, > > at the moment I'm testing unity 2.7.2. I have enabled different kind of > authenticators, one of the are local accounts with username password. I > have enabled the user registration on userhome too (see > userhome.properties config below), but the link "Register a new > account" from previous versions is not available on the userhome. Is > this behaviour intended? > And do you have a *public* registration form defined? Also it would be a good practice to enumerate on the home endpoint which of the public forms should be enabled there. Cheers, KB |
|
From: Sander A. <sa....@fz...> - 2018-11-15 13:31:22
|
Hi Krzysztof, at the moment I'm testing unity 2.7.2. I have enabled different kind of authenticators, one of the are local accounts with username password. I have enabled the user registration on userhome too (see userhome.properties config below), but the link "Register a new account" from previous versions is not available on the userhome. Is this behaviour intended? unity.userhome.attributes.1.attribute=cn unity.userhome.attributes.1.group=/ unity.userhome.attributes.1.showGroup=false unity.userhome.attributes.1.editable=true unity.userhome.attributes.2.attribute=mail unity.userhome.attributes.2.group=/ unity.userhome.attributes.2.showGroup=false unity.userhome.attributes.2.editable=true unity.userhome.attributes.3.attribute=o unity.userhome.attributes.3.group=/ unity.userhome.attributes.3.showGroup=false unity.user10home.attributes.3.editable=true unity.userhome.attributes.4.attribute=picture unity.userhome.attributes.4.group=/ unity.userhome.attributes.4.showGroup=false unity.userhome.attributes.4.editable=true unity.endpoint.web.enableRegistration=true unity.endpoint.web.authnScreenOptionsLabel.OR.text=OR unity.endpoint.web.authnGrid.G1.gridContents=samlWeb unity.endpoint.web.authnGrid.G1.gridRows=10 unity.endpoint.web.authnScreenColumn.1.columnSeparator=OR unity.endpoint.web.authnScreenColumn.1.columnWidth=17 unity.endpoint.web.authnScreenColumn.1.columnContents=pwdWeb unity.endpoint.web.authnScreenColumn.2.columnSeparator=OR unity.endpoint.web.authnScreenColumn.2.columnWidth=34 unity.endpoint.web.authnScreenColumn.2.columnContents=_GRID_G1 unity.endpoint.web.authnScreenColumn.3.columnSeparator=OR unity.endpoint.web.authnScreenColumn.3.columnWidth=17 unity.endpoint.web.authnScreenColumn.3.columnContents=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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
