These are chat archives for IdentityServer/Thinktecture.IdentityServer3

6th
Feb 2015
henrikniemann
@henrikniemann
Feb 06 2015 09:57
Hey all. I'm going to notify a web api of a successful local authentication. The web api of course requires an access token from my idserver. The plan is to act on the event "LocalLoginSuccess" in my custom eventservice, but what is the cool way to get an access token at that point and from "inside" idserver? Any thoughts?
John Korsnes
@johnkors
Feb 06 2015 10:29
hmm, you're going to call an API that is protected by bearer tokens inside the eventservice?
Dominick Baier
@leastprivilege
Feb 06 2015 11:02
well - create a client
and request a token using client credentials flow
you could probably also use the internal token service
but that could be wrapped up nicer i guess
well - besides if the token request triggers another event where you need a token....ouch ;)
henrikniemann
@henrikniemann
Feb 06 2015 11:13
Exactly! I can do it, but can't really decide on the nice way to do it. I might end up with letting the api accept basic authentication.
henrikniemann
@henrikniemann
Feb 06 2015 11:19
I want to start a process of updating some data from internal stores to Azure storage for the client to get when the user gets to the client and enters a specific area. Since this could take 5-60 seconds, we want the process to start as soon as possible, and before the user is redirected to client.
I want to start a process of updating some data from internal stores to Azure storage for the client to get when the user gets to the client and enters a specific area. Since this could take 5-60 seconds, we want the process to start as soon as possible, and before the user is redirected to client.
(Yeah, ok. I only wanna do it once...)
John Korsnes
@johnkors
Feb 06 2015 11:24
:D side effects. Seems you already got it
henrikniemann
@henrikniemann
Feb 06 2015 11:27
I suppose I could message the service bus directly...
John Korsnes
@johnkors
Feb 06 2015 11:28
henrikniemann
@henrikniemann
Feb 06 2015 12:08
Hmm. Does one of the events actually expose the actual issued and signed token in eventdetails somewhere? I could have the client request something like ResponseType = "id_token token", Scope = "openid orderhistory" and then catch the orderhistory access token and use it before redirecting the user? Sounds reasonable?
Manuel Rauber
@ManuelRauber
Feb 06 2015 12:09
@johnkors Just FYI ;) It is “danke schön” not “danke Schön” ;D
Dominick Baier
@leastprivilege
Feb 06 2015 12:09
i think for security reasons we don't
John Korsnes
@johnkors
Feb 06 2015 12:11
ach du liebe Zeit! Entschuldigung. Mein Fehler
i see alot of "username" in the events though. would be better if it was just the sub
henrikniemann
@henrikniemann
Feb 06 2015 12:16
Verdammt! #internationalfriday
Of course it's absolutely good from the security perspective.
John Korsnes
@johnkors
Feb 06 2015 12:24
we need to anonymize alot off logs due to personal data protection laws (and delete them after a certain while as well)
that's why I personally would prefer no username in the logs/events, but i guess not everyone has our requirement
henrikniemann
@henrikniemann
Feb 06 2015 12:27
It could be configurable. Or write a new logger based on IEventService. It's dead easy :-D
Dominick Baier
@leastprivilege
Feb 06 2015 12:28
open an issue for that when you have enough data
this is something we need to build into core
John Korsnes
@johnkors
Feb 06 2015 12:28
yeah, we already implemented both the log and eventservice. But the Event is a generic of any type, so I would have to know what to look for in my impl
enough data, @leastprivilege ?
Dominick Baier
@leastprivilege
Feb 06 2015 12:31
well - we already have a "include sensitive data in logs" setting
John Korsnes
@johnkors
Feb 06 2015 12:31
ah! did not know that..
Dominick Baier
@leastprivilege
Feb 06 2015 12:31
we could add somehting similar for the events
and once i know what to remove
we can add that feature
John Korsnes
@johnkors
Feb 06 2015 12:32
cool
Dominick Baier
@leastprivilege
Feb 06 2015 12:32
thats what it meant with "data"
John Korsnes
@johnkors
Feb 06 2015 12:32
yep, we have it all in elastic search. Could provide a list
Dominick Baier
@leastprivilege
Feb 06 2015 12:42
the idea is def that you don't have to do that
but rather set a config flag
John Korsnes
@johnkors
Feb 06 2015 12:42
yeah, i was thinking of providing you with a list of events that has for instance the username (in our case: email) in it
thought that was what you were asking for
Dominick Baier
@leastprivilege
Feb 06 2015 12:43
we could have an anonymize flag for events e.g.
since you are building a real word impl - that's good data
John Korsnes
@johnkors
Feb 06 2015 12:44
eventswithemail.PNG
my filter was "gmail" ;)
i'll open an issue
Dominick Baier
@leastprivilege
Feb 06 2015 12:45
thanks
John Korsnes
@johnkors
Feb 06 2015 12:46
nice!
henrikniemann
@henrikniemann
Feb 06 2015 12:47
"What he ^^ said" :-)
Dominick Baier
@leastprivilege
Feb 06 2015 12:47
:)
John Korsnes
@johnkors
Feb 06 2015 12:51
some of the events include state & nonce as well.. is that of any concern?
Dominick Baier
@leastprivilege
Feb 06 2015 12:51
nonce = a number used once
:) so prolly no
John Korsnes
@johnkors
Feb 06 2015 12:52
even in a failed login scenario?
it won't be "used once" until the redirect back to the RP, so short timespan to misuse it! :D
Dominick Baier
@leastprivilege
Feb 06 2015 12:53
yea maybe ;)
write it down - we'll think about it later :D
John Korsnes
@johnkors
Feb 06 2015 12:55
done, #882
also, IP is of concern, now that I think of it
Dominick Baier
@leastprivilege
Feb 06 2015 12:57
add it to the issue
we are planning some changes to eventing anyways
so let's collect ideas
henrikniemann
@henrikniemann
Feb 06 2015 13:00
In my world we would actually need "sensitive data" more often than normal. For trace and audit.
John Korsnes
@johnkors
Feb 06 2015 13:00
yep..
just had a meeting with the people creating a ToC for our service. Fun fun fun
it's not that we cannot keep sensitive stuff, but we are obliged to delete it after a timespan under certain criterias
depending on the contents of course
then ship it to the NSA
henrikniemann
@henrikniemann
Feb 06 2015 13:05
Lol. Yeah, sure. Compliance. I did SSO for global banks for a few years. And worked with ID Porten at some point :-)
John Korsnes
@johnkors
Feb 06 2015 13:06
ah, you're working in norway too?
henrikniemann
@henrikniemann
Feb 06 2015 13:08
No, but on a Norwegian project last year.
henrikniemann
@henrikniemann
Feb 06 2015 14:09
Great day, and now it's almost beer o'clock. Have a great weekend!
John Korsnes
@johnkors
Feb 06 2015 14:16
you too!
Brian Donahue
@briandonahue
Feb 06 2015 14:54
Is it possible to style the interim/implicit page in idsrv, after a user authenticates, when it posts back to the client app in Implicit flow? Sometimes our client apps are sloooow, and users see a white page and think idsrv/single-sign-on is broken :-D
Dominick Baier
@leastprivilege
Feb 06 2015 14:54
interim?
John Korsnes
@johnkors
Feb 06 2015 14:56
partial login that does nothing but show a spinner?
we're considering adding a spinner to login.html. The password check does take a while when your hashing alg is set to superman mode
Dominick Baier
@leastprivilege
Feb 06 2015 15:00
if that is generally applicable - we would appreciate the PR
Brian Donahue
@briandonahue
Feb 06 2015 15:01
It’s the login.html page? We have styled the main login page where they enter credentials, but after authenticating, when posting back to client, there is a blank white page (I believe this is the page with the js-submitted form to post back for implicit auth)?
I will see if I can replicate, to get exact url
John Korsnes
@johnkors
Feb 06 2015 15:02
we do hybrid, so different for us
Brian Donahue
@briandonahue
Feb 06 2015 15:09
It’s this guy:
/core/connect/authorize?client_id=atlas&redirect_uri=http%3A%2F%2Flocalhost%2Fmldb.website%2F&response_mode=form_post&response_type=id_token&scope=openid%20email%20profile&state=….
I was thinking of adding something like “You have been authenticated, waiting for [client name] to respond” or some such :-D
John Korsnes
@johnkors
Feb 06 2015 15:14
yeah, not sure what you see as a white page. Never experienced that.. I'll add a thread.sleep in my sample RP and see if I can repro
John Korsnes
@johnkors
Feb 06 2015 15:33
see what you mean, yeah
         MessageReceived = async n =>
                {
                     Thread.Sleep(10000);                        
                },
for a implicit client, there's a white page
not sure if Katana supports fragment Responsemode, so wasn't able to test that up against form_post
John Korsnes
@johnkors
Feb 06 2015 15:39
is it client warmup thing, or are your clients always slow :D
Dominick Baier
@leastprivilege
Feb 06 2015 15:54
John Korsnes
@johnkors
Feb 06 2015 16:38
You mean the redirect to http?
I thought you wouldnt notice ;)
John Korsnes
@johnkors
Feb 06 2015 16:49
i'm calling an API hosted on appharbor that runs http, and I was too cheap to pay for an SSL cert. http://localeapi.apphb.com/ that's why I do the redirect. If that was what you were thinking of.
John Korsnes
@johnkors
Feb 06 2015 17:01
... or is this a riddle. I hate riddles. I'm really bad at them ;)
Brian Donahue
@briandonahue
Feb 06 2015 19:17
@johnkors it’s mainly a cient warm-up thing, just a lot of deployments going on lately, across a couple servers, so we get sporadic “Single Sign-On is SLOW!!!” reports, when it’s really not that.
John Korsnes
@johnkors
Feb 06 2015 19:30
ah
so you don't initiate the flow from the same slow client