Perl 6 - the future is here, just unevenly distributed

IRC log for #openam, 2017-04-23

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:49 ilbot3 joined #openam
01:49 Topic for #openam is now Chat about the OpenAM project - https://forgerock.github.io - Channel logs at: http://irclog.perlgeek.de/openam/today
03:15 jasoninmel joined #openam
06:43 aldaris joined #openam
07:42 jasoninmel joined #openam
11:39 jasoninmel joined #openam
19:21 aldaris joined #openam
19:33 aldaris joined #openam
19:46 aldaris joined #openam
19:55 aldaris joined #openam
20:32 aldaris joined #openam
21:14 jasoninmel joined #openam
21:17 jasoninmel https://forum.forgerock.com/topic/saml2exception-multiple-matching-users-found/
21:17 aldaris hi
21:17 jasoninmel updated the topic with version
21:17 aldaris it's an EOSL version
21:17 aldaris so what do you expect
21:17 aldaris and you have a problem in custom code
21:17 aldaris (shrug)
21:18 jasoninmel hi alsaris, is there a reason to say the issue is with custom code?
21:19 aldaris the forum is not really the best place to ask for professional advice on how to implement a custom extension. Given that this would also need a lot of investigation work, it really doesn't fit there well
21:19 aldaris I'm petermajor on the forum, I have already replied on your previous topic
21:19 jasoninmel the topic is not about writing custom code
21:21 jasoninmel I'm suspecting it's a defect in core SSO module
21:22 jasoninmel looking for some advice on where to look
21:22 aldaris and all I'm saying is that it is probably not an AM issue
21:22 jasoninmel anything to confirm the rootcause
21:23 jasoninmel how did you come to that conclusion?
21:23 aldaris look at replication, look at when you create duplicate entries. Add extra debug code into your mapper that prints out whether it found users with the same unique data already
21:24 jasoninmel i've done all that but couldn't find any issue with account mapper
21:24 aldaris if it works most of the time, then it doesn't feel like a functional issue with AM
21:25 jasoninmel hence the reason to seek advice
21:25 jasoninmel hmm
21:25 aldaris you should add more debug logging and wait for the event to happen
21:26 jasoninmel :)
21:26 aldaris you will probably find that the mapper couldn't find the already existing user
21:26 jasoninmel ok
21:27 aldaris if you have timestamped code with all the UUIDs involved, you should be able to track down whether it is a timing issue, or replication issue, or something nasty like an AM issue (around search?)
21:27 jasoninmel the mapper check if user exist immediately before adding
21:27 aldaris the DJ access logs will tell you when the entries are created, and when the entry is replicated to the other nodes
21:27 jasoninmel i have the time each uuid created
21:28 jasoninmel they are created even few days apart
21:28 jasoninmel so this is not a race condition
21:29 aldaris then I'm gonna guess case sensitive attribute and case insensitive input
21:30 aldaris that would explain why the search doesn't find it, but it doesn't explain why the profile search fails later - unless you are using a different attribute to find the profile
21:30 aldaris is the user entry created on the same user data store node?
21:30 jasoninmel you mean the IDP sending user id attribute with lower case and uppercase?
21:30 aldaris are you using DJ?
21:31 jjpp iff the search before add does not find the user then i would check what exactly is queried from opendj. and.. it is a bit unclear how many opendjs and how many openams there is..
21:31 jasoninmel I'm using sun directory server
21:31 aldaris you like to live in the past, I see :)
21:32 jasoninmel :)
21:32 jasoninmel oracle
21:33 jasoninmel i have checked the user search in ldap log and haven't seen any difference between the original account search vs duplicates
21:34 aldaris does "nentries" say 0?
21:35 jasoninmel for first search by account mapper yes
21:35 jasoninmel but for subsequent search it returns more than one
21:36 aldaris even for the search just before the second add?
21:36 jasoninmel yes
21:36 jasoninmel that's why i don't believe it's a account mapper issue
21:37 aldaris then check your code and add some debugging that tells how many entries were found from the search
21:37 aldaris if it's 1, something in your custom code is dodgy
21:37 jasoninmel cool
21:37 jasoninmel i will do that
21:37 aldaris if it's 0, something in AM core is wrong
21:38 aldaris if there was an exception, you'll want to trace that too :)
21:38 jasoninmel that's what i'm suspecting anyway though I haven't been able to proove
21:39 jasoninmel all the exceptions i've added are from core sso modules
21:39 jasoninmel not from the account mapper
21:40 jasoninmel but i will check what type of errors are thrwon by account mapper if more than one account found
21:41 jjpp if there is an exception you will want to understand what exactly causes it. it could very well be that your custom code messes with assumptions made elsewhere in the code. eg. by writing "illegal"/unexpected values to ldap..
21:42 jasoninmel what does illegal universal identifier mean?
21:42 jjpp (not knowing what your custom code does exactly.. we have the freedom of claiming anything, of course:)
21:43 aldaris that you can ignore that error :)
21:43 jasoninmel oh ok
21:44 jjpp but it definitley is instructive to understand why he can ignore it? :)
21:44 jasoninmel i thought that error is the closest clue
21:45 aldaris haven't seen a case yet when it was actually relevant
21:45 jasoninmel2 joined #openam
21:45 aldaris and that's true for the past 5,5 years now
21:45 jasoninmel2 yeag it would be good to know why that error can be ignored
21:46 jasoninmel2 sorry i think i missed your last comment aldaris
21:46 jasoninmel2 :(
21:46 aldaris that's why you have a link to the logs in the room topic
21:48 jasoninmel2 anyway i will try to add more debug output to see if i can identify the rootcause
21:48 jasoninmel2 thanks for the help guys
21:49 aldaris now this conversation on the topic would have taken ages and lots of replies :)
22:00 jasoninmel joined #openam
22:02 jasoninmel certainly, that's why i love this. and having experts in the room to support is awesome
22:03 aldaris keep in mind that best time to ask questions is within the GMT/BST timezone's work day

| Channels | #openam index | Today | | Search | Google Search | Plain-Text | summary