Perl 6 - the future is here, just unevenly distributed

IRC log for #openam, 2017-02-14

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

All times shown according to UTC.

Time Nick Message
01:21 aldaris joined #openam
01:21 aldaris joined #openam
01:22 aldaris joined #openam
01:23 aldaris joined #openam
01:24 aldaris joined #openam
01:24 aldaris joined #openam
02:08 aldaris joined #openam
02:48 ilbot3 joined #openam
02:48 Topic for #openam is now Chat about the OpenAM project - https://backstage.forgerock.com/#/downloads - OpenAM 13.5.0 is out! OpenAM 12.0.4 is out! Channel logs at: http://irclog.perlgeek.de/openam/today
08:26 aldaris joined #openam
09:09 KermitTheFragger joined #openam
10:27 jjpp hm. openam is fragile. every time i try to abuse it, it will break. :(
10:33 KermitTheFragger jjpp: I know what you mean :(
10:36 jjpp aldaris: yesterdays glitch was because of me replacing the old session in login state during authentication. which is probably not nice. but there still is/was something fishy with session handling there.
10:37 aldaris well if you abuse it, it will fight back - I hope
10:37 aldaris so stop with the abuse maybe?
10:37 jjpp loginstate.setsessionproperties doing session = oldSession (without updating sid) and doing it instead using updateSessionProperty does not feel nice either.. :(
10:41 jjpp well.. yeah, the sad thing is that .. actually we should reconsider if openam and the way we use it, makes sense. especially considering the source-accessibility issues and those at least two regressions that i have stumbled upon lately (renaming json api parameters without any reason; breaking crosstalk and making us require stickyness for openam lb)..
10:42 aldaris the session upgrade related code should be better since 13+, the different session upgrade modes now have different session activator impls
10:44 jjpp yeah, the "abuse part" probably relyied on something that was fixed since 11. although the difference in LoginState does not feel too big.
10:45 jjpp but i imagine that it has already gotten even better.
10:53 * jjpp thinks . o O ( and somehow i feel that it would be really useful to see the last/trunk version of LoginState.java.. :( )
11:39 * jjpp thinks . o O ( hm, is there a modern and easy way to get "vanilla openam13 installation"? to test if I can recreate the issue i am having there, so that you could check if that is fixed in 13.5? )
11:56 KermitTheFragger jjpp: https://github.com/dj-wasabi/docker-openam
12:00 jjpp sounds like i would need to install/learn docker for that? :)
12:00 jjpp also, how "vanilla" it is?
12:05 jjpp (took openam13 and fresh tomcat8, we'll see..)
12:17 MegaMatt joined #openam
12:38 KermitTheFragger jjpp: define "Vanilla" :-)
12:39 KermitTheFragger from what I can see it is from the 13.0.0 tag in VCS
12:39 KermitTheFragger doesn't get more vanilla then that I think :-)
12:39 KermitTheFragger there is also the Forgerock Vagrant repo: https://github.com/ForgeRock/frstack
12:39 KermitTheFragger personally I liked the docker one better because it was simpler
12:43 jjpp well, then it is vanilla enough, i guess.
12:44 jjpp anyway. i have managed to recreate the problem with openam 13 dist just downloaded from forgerock.
12:45 jjpp i probably should create an issue. and then _perhaps_ aldaris can look at it and say if it is fixed in 13.5. not that it would help me other than give a warm and fuzzy feeling. :(
13:23 MegaMatt joined #openam
13:36 jjpp aldaris: https://bugster.forgerock.o​rg/jira/browse/OPENAM-10619
13:37 jjpp I feel much better if you say that LoginState and friends are actually refactored since 13.0 although then i am a bit more than a bit sad because i cannot access that goodness, yet. :(
13:40 aldaris jjpp: meh
13:41 jjpp hm, forget the emotional tone. objectively: there is something fishy going on even in vanilla 13.0
13:42 jjpp it could be that it is already refactored to be better.
13:42 aldaris that bug report is way too verbose, whilst also mostly unhelpful - as it doesn't really describe what functionality is lost and how
13:43 jjpp the title should say that. my pap does not run during session upgrade.
13:43 aldaris also invalid session id stacktraces are 99% useless
13:44 jjpp hm, yeah.. i could actually add the part where LoginState/authcontext is created and the later-to-be-not-found session is created (in the same request, in the same thread)
13:45 jjpp the full authentication debuglog contains some irrelevant misfires, unfortunately
13:45 aldaris it would be more helpful to know whether this was a pure session upgrade, an arg=newsession flow, or a forceauth attempt
13:46 aldaris you know curl commands and alike
13:46 aldaris that would make it much simpler to reproduce
13:46 jjpp curl commands are there
13:46 jjpp though, i am not particularly good at formatting them well in jira :(
13:48 aldaris openam-10250 can be related
13:48 aldaris forceauth in general is a bit broken in 13 I think
13:49 jjpp in a nutshell: 1. auth against ldapService chain with username/password in headers -- succeeds and pap runs. 2. session upgrade, without newsession, with forceauth. auth succeeds but one can see logSuccess and starting PAP fail in log..
13:50 jjpp both of those last 2 fails are IMHO because loginstate.sid is of the newly created session that is not valid.
13:51 jjpp i guess the difference with openam11 (that had this part working) is that loginstate.getssotoken did not use to check session validity before, but that is a guess.
13:51 jjpp also, during force auth the newly created session is actually not used for anything. so.. using that for logging or pap is a problem as well.
13:54 jjpp and yes, it seems that there are two competing semantics of forceauth -- "do the auth even if session has doing that kind of auth before" and "return the old session after session upgrade"
13:54 jjpp and it still boils down to "LoginState and friends must be refactored"
13:55 jjpp (which probably is really painful, if there are paying customers using clientsdk and whatever misbehavings the state of the art has)
15:39 Jim__ joined #openam
17:00 Jim__ Hi folks, I need some advise on something I've been banging my head against for several days now
17:01 Jim__ I have a need to get a session token issued for users without a password (impersonation)
17:01 Jim__ I understand there is a beta impersonation module, but I would prefer to do it with out-of-the-box modules for supportability.
17:03 Jim__ The use cases are that we are writing a custom login application that includes "remember me" functionality, and we also have a highly audited impersonation application whereby select administrators are allowed to impersonate select users in order to troubleshoot reported problems with applications.
17:04 Jim__ I have looked into using the Anonymous module and the scripted module, without luck.
17:05 Jim__ Is there a module I should be looking at instead?
21:01 aldaris joined #openam

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