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
(2) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
From: Krzysztof B. <kb...@un...> - 2017-03-28 21:59:33
|
W dniu 28.03.2017 o 14:49, Willem Elbers pisze: > Dear Krzystof, > > in addition to this issue, is it possible to change the component user > to render an attribute in the registration form? > > Instead of the combo box it could be nice to use a list component (as > used in the "attribute types management" attribute type editor). > > Or even better a search option which dynamically filters the results. I think that the list component is not a good approach - would occupy a lot of space always, would be quite ugly for couple of say 3-4 elements enums on reg screen. I've turned on search/filtering - indeed it was not enabled. So now you will be able to type to filter the selection in the usual way. Best, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2017-03-28 21:17:47
|
Dear Willem, W dniu 28.03.2017 o 16:49, Willem Elbers pisze: > Dear Krzysztof, > > we are using account invitations now to import existing users into unity > IDM. > We create the invitations via the REST interface. Our identities are > email based and require confirmation. > > We have noticed that when creating an invitation with a prefilled email > value, with the confirmed option checked (see attached screenshot), > unity is still sending email confirmation messages. > > Is it possible to mark these email addresses as confirmed without > sending the mails to the end users? (We are using the same email address > to send the invitation, so the email address is already confirmed). Yes, however only if you set the prefill mode to anything else than the "Value will be used as a default". If this is set as default this value is only a hint, but it is not treated specially (user can change it) and confirmation state is not preserved. When this is either hidden or presented read-only then the confirmation state should be preserved - the value from invitation is used directly. HTH, Krzysztof |
From: Willem E. <wi...@cl...> - 2017-03-28 14:49:52
|
Dear Krzysztof, we are using account invitations now to import existing users into unity IDM. We create the invitations via the REST interface. Our identities are email based and require confirmation. We have noticed that when creating an invitation with a prefilled email value, with the confirmed option checked (see attached screenshot), unity is still sending email confirmation messages. Is it possible to mark these email addresses as confirmed without sending the mails to the end users? (We are using the same email address to send the invitation, so the email address is already confirmed). Best, Willem -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Willem E. <wi...@cl...> - 2017-03-28 12:49:27
|
Dear Krzystof, in addition to this issue, is it possible to change the component user to render an attribute in the registration form? Instead of the combo box it could be nice to use a list component (as used in the "attribute types management" attribute type editor). Or even better a search option which dynamically filters the results. Best, Willem On 28/03/17 10:08, Willem Elbers wrote: > Dear Krzysztof, > > We've observed this in drop down lists (based on enumerated attributes) > in the account registration form. > > Best, > > Willem > > > On 27/03/17 23:16, Krzysztof Benedyczak wrote: >> Dear Willem, >> >> W dniu 27.03.2017 o 10:48, Willem Elbers pisze: >>> Dear Krzysztof, >>> >>> currently values in an enumeration seems to be displayed randomly (not >>> alphabetical and also not in order of addition). >>> >>> Is it possible to display these values in some sorted way? Preferably >>> alpabetical. >> Sure we can improve this, but can you please be more precise - where >> is this issue? >> >> Cheers, >> Krzysztof >> -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Willem E. <wi...@cl...> - 2017-03-28 08:10:00
|
Dear Krzysztof, this is not high priority. We can switch to plain text emails for now. However it is a nice to have. Best, Willem On 27/03/17 23:13, Krzysztof Benedyczak wrote: > Hi Willem, > > W dniu 24.03.2017 o 10:45, Willem Elbers pisze: >> Dear Krzysztof, >> >> is it possible to change the email content encoding (Content-Type >> header) for the email notification channel to "text/html" (instead of >> the default "text/plain")? > > Unfortunately not. I can open a FR about this if this is an important > issue, however this is bit bigger work then other things you reported. > > Best, > Krzysztof -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Willem E. <wi...@cl...> - 2017-03-28 08:08:54
|
Dear Krzysztof, We've observed this in drop down lists (based on enumerated attributes) in the account registration form. Best, Willem On 27/03/17 23:16, Krzysztof Benedyczak wrote: > Dear Willem, > > W dniu 27.03.2017 o 10:48, Willem Elbers pisze: >> Dear Krzysztof, >> >> currently values in an enumeration seems to be displayed randomly (not >> alphabetical and also not in order of addition). >> >> Is it possible to display these values in some sorted way? Preferably >> alpabetical. > > Sure we can improve this, but can you please be more precise - where > is this issue? > > Cheers, > Krzysztof > -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Krzysztof B. <kb...@un...> - 2017-03-27 21:16:53
|
Dear Willem, W dniu 27.03.2017 o 10:48, Willem Elbers pisze: > Dear Krzysztof, > > currently values in an enumeration seems to be displayed randomly (not > alphabetical and also not in order of addition). > > Is it possible to display these values in some sorted way? Preferably > alpabetical. Sure we can improve this, but can you please be more precise - where is this issue? Cheers, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2017-03-27 21:13:26
|
Hi Willem, W dniu 24.03.2017 o 11:03, Willem Elbers pisze: > Hi Krzysztof, > > we have observed an issue with the display of html added to the > description of a password credential definition in the credential > management section of /home/home, see the attached image. > > This is the case while using "unityServer.core.allowFullHtml=true", > which does work in other parts of the UI. > > Related to this issue (we try to explain the password requirements with > a html list <ul></ul>); is it possible to have an indication of the > password requirements in the screens where a user has to set / update a > password? If not, this would be a feature request. Yeah, it is not working as expected - or better said - not in consistent way as for registration form asking about credential properly interprets HTML (assuming allowFullHtml=true). I've opened a ticket about this - it is trivial to fix. Seems that only 2 places are affected: RO credential view in Admin UI + the aforementioned HomeUI screen. Thanks, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2017-03-27 21:13:20
|
W dniu 24.03.2017 o 10:43, Willem Elbers pisze: > While testing this can work, for real user accounts this is not really a > nice work around. OK, opened a FR about this. At least for identities this might be handy in Admin UI (and is easy to add). Best, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2017-03-27 21:13:16
|
Hi Willem, W dniu 24.03.2017 o 10:45, Willem Elbers pisze: > Dear Krzysztof, > > is it possible to change the email content encoding (Content-Type > header) for the email notification channel to "text/html" (instead of > the default "text/plain")? Unfortunately not. I can open a FR about this if this is an important issue, however this is bit bigger work then other things you reported. Best, Krzysztof |
From: Willem E. <wi...@cl...> - 2017-03-27 08:48:54
|
Dear Krzysztof, currently values in an enumeration seems to be displayed randomly (not alphabetical and also not in order of addition). Is it possible to display these values in some sorted way? Preferably alpabetical. Best, Willem -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Willem E. <wi...@cl...> - 2017-03-24 10:03:32
|
Hi Krzysztof, we have observed an issue with the display of html added to the description of a password credential definition in the credential management section of /home/home, see the attached image. This is the case while using "unityServer.core.allowFullHtml=true", which does work in other parts of the UI. Related to this issue (we try to explain the password requirements with a html list <ul></ul>); is it possible to have an indication of the password requirements in the screens where a user has to set / update a password? If not, this would be a feature request. Best, Willem -- Willem Elbers CLARIN ERIC www.clarin.eu | skype: wjm.elbers |
From: Willem E. <wi...@cl...> - 2017-03-24 09:45:29
|
Dear Krzysztof, is it possible to change the email content encoding (Content-Type header) for the email notification channel to "text/html" (instead of the default "text/plain")? Best, Willem -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Willem E. <wi...@cl...> - 2017-03-24 09:43:21
|
Dear Krzysztof, On 23/03/17 23:55, Krzysztof Benedyczak wrote: > Dear Willem, > > W dniu 23.03.2017 o 14:00, Willem Elbers pisze: >> Dear Krysztof, >> >> we've recently encountered an issue where a user clicked the link in the >> email confirmation email. However, the entity within unity-idm wasn't >> updated and still showed "[confirmation request sent]" in the entity >> details. > > Do you have any more information? There was some problem shown on the > confirmation page? Maybe the link has expired? > Unfortunately not. The user got the activation successful message and I didn't find any exceptions in the log file. The link was clicked within 90 minutes after account creation, so I doubt it was expired. >> >> is it possible to resend the email verification link? >> >> (we've removed the entity for now and after recreating it, everything >> worked as expected) > > Yes it is. You can easily trigger this using REST API: > > @Path("/confirmation-trigger/identity/{type}/{value}") > @POST > > Triggers sending of confirmation message of identity. Nearly always it > is a re-send. > > @Path("/confirmation-trigger/entity/{entityId}/attribute/{attributeName}") > > @QueryParam("group") > @QueryParam("identityType") > @POST > > Triggers sending of confirmation message for an attribute. Nearly > always it is a re-send. Ok thanks. I was hoping for an easy way to do this from the UI. > > > What is more you can quite easily force unity to re-send email > *attribute* confirmation from Admin UI: edit the attribute, set is a > confirmed, save, edit again and set back to not-confirmed state. > It is hard to do this for identity. You can remove identity (removing > the whole entity is rather too brutal ;) and re-add it. However this > may loose some context (e.g. metadata of identity real origin). While testing this can work, for real user accounts this is not really a nice work around. > > Cheers, > Krzysztof Best, Willem -- Willem Elbers CLARIN ERIC www.clarin.eu | tel: +31-(0)85-0091277 | skype: wjm.elbers |
From: Krzysztof B. <kb...@un...> - 2017-03-23 22:55:34
|
Dear Willem, W dniu 23.03.2017 o 14:00, Willem Elbers pisze: > Dear Krysztof, > > we've recently encountered an issue where a user clicked the link in the > email confirmation email. However, the entity within unity-idm wasn't > updated and still showed "[confirmation request sent]" in the entity > details. Do you have any more information? There was some problem shown on the confirmation page? Maybe the link has expired? > > is it possible to resend the email verification link? > > (we've removed the entity for now and after recreating it, everything > worked as expected) Yes it is. You can easily trigger this using REST API: @Path("/confirmation-trigger/identity/{type}/{value}") @POST Triggers sending of confirmation message of identity. Nearly always it is a re-send. @Path("/confirmation-trigger/entity/{entityId}/attribute/{attributeName}") @QueryParam("group") @QueryParam("identityType") @POST Triggers sending of confirmation message for an attribute. Nearly always it is a re-send. What is more you can quite easily force unity to re-send email *attribute* confirmation from Admin UI: edit the attribute, set is a confirmed, save, edit again and set back to not-confirmed state. It is hard to do this for identity. You can remove identity (removing the whole entity is rather too brutal ;) and re-add it. However this may loose some context (e.g. metadata of identity real origin). Cheers, Krzysztof |
From: Willem E. <wi...@cl...> - 2017-03-23 13:00:46
|
Dear Krysztof, we've recently encountered an issue where a user clicked the link in the email confirmation email. However, the entity within unity-idm wasn't updated and still showed "[confirmation request sent]" in the entity details. is it possible to resend the email verification link? (we've removed the entity for now and after recreating it, everything worked as expected) Best, Willem -- Willem Elbers CLARIN ERIC www.clarin.eu | skype: wjm.elbers |
From: Krzysztof B. <kb...@un...> - 2017-03-21 06:58:24
|
Shiraz, W dniu 20.03.2017 o 12:45, Shiraz Memon pisze: > Hi Krzysztof, > > In addition to Sander's concerns about release of extra (or unwanted) > attributes to the relying parties, it would also be interesting to know > whether unity allows preventing users from hiding the released (or about > to be released) attributes on the consent screen. So, here I mean, to > block the possibility for the end users to hide the "important" > attributes, which we as an authentication service are committed to > release as a proxy IdP. > > unity.saml.skipConsent=true (and similar for oauth) allows for this, however if you need to keep consent screen but only disable control of exposed information then a new feature is needed. Best, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2017-03-21 06:54:03
|
Hi Sander, W dniu 20.03.2017 o 09:33, Sander Apweiler pisze: > Hi Krzysztof, all, > > I'm redesigning our output translation profiles. Therefore I start with > new translation profile with small information. I want to reduce the > output for users in confirmation screen. My output translation profile > (whole profile below) has only four rules, but the confirmation screen > lists eight attributes. Some of them are not requested and not released > by translation profile. So is there a mix up with default output > translation profile? If yes, is it possible to avoid this mix up? As you can read in output profile documentation: 'Output translation profile operates on a data structure which is initially filled by Unity with all attributes and identities of the queried principal. Attributes are from the group configured in the endpoint.' The default profile merely adds dynamic memberOf attribute which is commonly requested. All of this happens as we want to have the most sensible defaults without any output profile. If you want to have a full control over all attributes using your output profile start it from filtering rules. E.g. to filter all attributes use the filterAttribute with .* argument. You can then either "un-hide" selected attribute or release all dynamic ones using createAttribute rule. Cheers, KB |
From: Shiraz M. <a....@fz...> - 2017-03-20 11:47:15
|
Hi Krzysztof, In addition to Sander's concerns about release of extra (or unwanted) attributes to the relying parties, it would also be interesting to know whether unity allows preventing users from hiding the released (or about to be released) attributes on the consent screen. So, here I mean, to block the possibility for the end users to hide the "important" attributes, which we as an authentication service are committed to release as a proxy IdP. Cheers, Shiraz On Mon, Mar 20, 2017 at 10:33 AM, Sander Apweiler <sa....@fz... > wrote: > Hi Krzysztof, all, > > I'm redesigning our output translation profiles. Therefore I start with > new translation profile with small information. I want to reduce the output > for users in confirmation screen. My output translation profile (whole > profile below) has only four rules, but the confirmation screen lists eight > attributes. Some of them are not requested and not released by translation > profile. So is there a mix up with default output translation profile? If > yes, is it possible to avoid this mix up? > > Here are some information about my system: > unity 1.9.5 > > Output translation profile: > 1. condition: true > Action: createAttribute > AttributeName: urn:oid:1.2.840.113549.1.9.1 > expression: attr['mail'].toString() > 2. condition: true > Actiopn: createAttribute > attributeName: urn:oid:2.5.4.3 > expression: attr['cn'] > 3. condition: idsByType contains 'persistent' > Action: createAttribute > attributeName: unity:persistent > expression: idsByType['persistent'] > 4. condition: (requester contains 'URL') > Action: createAttribute > attribuetName: memberOf > expression: groups + ['FSD2'] > > Requested Attributes from SP are: unity:persistent, > urn:oid:1.2.840.113549.1.9.1, cn, memberOf > > confirmation screen lists: > 1. mail > 2. unity:persistent > 3. memberOf > 4. sys:FilledEnquires > 5. cn > 6. urn:oid:1.2.840.113549.1.9.1 > 7. urn:oid:2.5.4.3 > 8. o > > So first it looks like email and cn which are created in urn:oid notation > in translation profile are released with their internal names too. > Organisation Name and sys:FilledEnquires was wether released within > translation profile nor requested by SP but they are released too. Do you > know the reason for this behaviour? > > Best regards, > Sander > > -- > > Federated Systems and Data > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 <02461%20618847> > fax: +49 2461 61 6656 <02461%20616656> > 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 > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > -- Shiraz Memon Federated Systems and Data Jülich Supercomputing Centre (JSC) Phone: +49 2461 61 6899 Fax: +49 2461 61 6656 |
From: Sander A. <sa....@fz...> - 2017-03-20 08:33:41
|
Hi Krzysztof, all, I'm redesigning our output translation profiles. Therefore I start with new translation profile with small information. I want to reduce the output for users in confirmation screen. My output translation profile (whole profile below) has only four rules, but the confirmation screen lists eight attributes. Some of them are not requested and not released by translation profile. So is there a mix up with default output translation profile? If yes, is it possible to avoid this mix up? Here are some information about my system: unity 1.9.5 Output translation profile: 1. condition: true Action: createAttribute AttributeName: urn:oid:1.2.840.113549.1.9.1 expression: attr['mail'].toString() 2. condition: true Actiopn: createAttribute attributeName: urn:oid:2.5.4.3 expression: attr['cn'] 3. condition: idsByType contains 'persistent' Action: createAttribute attributeName: unity:persistent expression: idsByType['persistent'] 4. condition: (requester contains 'URL') Action: createAttribute attribuetName: memberOf expression: groups + ['FSD2'] Requested Attributes from SP are: unity:persistent, urn:oid:1.2.840.113549.1.9.1, cn, memberOf confirmation screen lists: 1. mail 2. unity:persistent 3. memberOf 4. sys:FilledEnquires 5. cn 6. urn:oid:1.2.840.113549.1.9.1 7. urn:oid:2.5.4.3 8. o So first it looks like email and cn which are created in urn:oid notation in translation profile are released with their internal names too. Organisation Name and sys:FilledEnquires was wether released within translation profile nor requested by SP but they are released too. Do you know the reason for this behaviour? 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...> - 2017-03-14 11:22:22
|
Hi, W dniu 14.03.2017 o 11:43, Shiraz Memon pisze: > Hi, > > Is it possible to get the metadata file generated for saml sp and/or idp > with the following custom extensions? > > <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://aai.egi.eu/saml2/idp/metadata.php"> > <md:Extensions> > <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> > <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="http://macedir.org/entity-category-support" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string"> > http://refeds.org/category/research-and-scholarship > </saml:AttributeValue> > </saml:Attribute> > <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://aai.egi.eu/LoA#Low</saml:AttributeValue> > <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://aai.egi.eu/LoA#Substantial</saml:AttributeValue> > <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://aai.egi.eu/LoA#High</saml:AttributeValue> > <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://refeds.org/sirtfi</saml:AttributeValue> > </saml:Attribute> > </mdattr:EntityAttributes> > </md:Extensions> > ..... > Generated - not. However you can auto generate the default MD, edit it inserting custom extensions and then configure Unity to return your customized file instead of the autogenerated metadata. Cheers, Krzysztof |
From: Shiraz M. <a....@fz...> - 2017-03-14 10:44:13
|
Hi, Is it possible to get the metadata file generated for saml sp and/or idp with the following custom extensions? <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" entityID="https://aai.egi.eu/saml2/idp/metadata.php"> <md:Extensions> <mdattr:EntityAttributes xmlns:mdattr="urn:oasis:names:tc:SAML:metadata:attribute"> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="http://macedir.org/entity-category-support" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string"> http://refeds.org/category/research-and-scholarship </saml:AttributeValue> </saml:Attribute> <saml:Attribute xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Name="urn:oasis:names:tc:SAML:attribute:assurance-certification" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://aai.egi.eu/LoA#Low</saml:AttributeValue> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://aai.egi.eu/LoA#Substantial</saml:AttributeValue> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://aai.egi.eu/LoA#High</saml:AttributeValue> <saml:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">https://refeds.org/sirtfi</saml:AttributeValue> </saml:Attribute> </mdattr:EntityAttributes> </md:Extensions> ..... 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: Krzysztof B. <kb...@un...> - 2017-03-01 23:32:52
|
Dear Subscribers, Subsequent Unity revision - 1.9.5 - is available for download. In the first place it fixes recently found bugs. Additionally one new feature is introduced: it is possible to configure what happens when user triggers account removal (for instance it can be only disabled if some more complicated deprovisioning should be activated). Download links and detailed list of changes is available at: http://www.unity-idm.eu/site/downloads Best regards, Krzysztof |
From: Krzysztof B. <kb...@un...> - 2017-03-01 23:28:51
|
Hi Sander, W dniu 01.03.2017 o 15:42, Sander Apweiler pisze: > Hi all, > > I created a new registration form for an additional IdP. Because I'm > not sure if CN is release I chosed "Can be provided by remote IdP; if > not then collected interactively" as was to collect the value. The > manual says: "In this mode the user can fill the data only if it was > not provided by a remote IdP. If it was provided by remote IdP then > this data is hidden in the form." > > The registration form asked me for CN although the IdP has released the > CN. The CN value from IdP was not displayed in registration form. I > entered another CN than the IdP provided. After reading the attributes > in userhome i saw, unity used the CN from IdP and not from user. > > As admin I expect, that CN from IdP is shown in the form or CN is not > collected in form if the IdP provided it. Like it is written in manual. > As user it i don't know why there stored values differs from my input. > Is this behaviour wanted? No, what you described is a bug in UI: in the described case there should be no textfield collecting cn in the form. The rest (use of the remote IdP-provided value) is correct. Will be fixed in the 1.9.5. > Is there a release date for next unity? Yes: couple of minutes ago :-) Best, Krzysztof |
From: Sander A. <sa....@fz...> - 2017-03-01 14:42:39
|
Hi all, I created a new registration form for an additional IdP. Because I'm not sure if CN is release I chosed "Can be provided by remote IdP; if not then collected interactively" as was to collect the value. The manual says: "In this mode the user can fill the data only if it was not provided by a remote IdP. If it was provided by remote IdP then this data is hidden in the form." The registration form asked me for CN although the IdP has released the CN. The CN value from IdP was not displayed in registration form. I entered another CN than the IdP provided. After reading the attributes in userhome i saw, unity used the CN from IdP and not from user. As admin I expect, that CN from IdP is shown in the form or CN is not collected in form if the IdP provided it. Like it is written in manual. As user it i don't know why there stored values differs from my input. Is this behaviour wanted? Is there a release date for next unity? 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 ----------------------------------------------------------------------- ----------------------------------------------------------------------- |