These are chat archives for IdentityServer/Thinktecture.IdentityServer3

2nd
Feb 2015
Brock Allen
@brockallen
Feb 02 2015 00:00
ok, so @johnkors -- the issue is that ResourceManager.GetString allows for case insensitive matches? is that why i never noticed the issue?
Brock Allen
@brockallen
Feb 02 2015 00:26
ok, so i've fixed this by fixing the T4. i think that's the right approach to this.
it's now checked in on dev -- please have a look and see if that's better for you
Khushal Patel
@khushalpatel1981
Feb 02 2015 06:35
can anyone direct me to the path of implement resource owner flow in windows phone 8.1, included app in sample is not working...
Khushal Patel
@khushalpatel1981
Feb 02 2015 06:44
It's always saying "User cancelled authentication" when i clicked on any button given on screen
John Korsnes
@johnkors
Feb 02 2015 11:27
@brockallen I'm not sure, but I think the issue was that idsrv did not "eat it's own dog food". I believe that internally idsrv sends different ids to the localizationservice than the public ones defined in MessageIds, EventIds and ScopeIds (that implementors should use).
and DefaultLocalizationService used resxs that matched those of idsrv internals, and not the public ids (MessageIds, EventIds and ScopeIds)
if you write a test against the DefaultLocalizationService trying to fetch using ids from MessageIds, EventIds and ScopeIds, it would (before the fix in dev) provide nulls. If you use what idsrv uses at runtime (not the public ids), it works. That's why the default localization service works.
Richard Bennett
@dealproc
Feb 02 2015 11:57
will look at docs... but is there a "base" exception to inherit from if i want IdSrv to capture something and handle it?
henrikniemann
@henrikniemann
Feb 02 2015 14:02
Hey all, but maybe mostly @ManuelRauber. I'm trying to work out what's up and down with the Admin projects. I see client UI was merged into admin, but what are the relations on admin / client / admin.ef now? I'm thinking project admin is the "main" one, client is dead/merged and ef will be updated when admin is done'ish. Am I close?
Brock Allen
@brockallen
Feb 02 2015 14:30
@henrikniemann Admin is main, Admin.Ef is EF implementation (of course)
at least on the branch, unless @ManuelRauber merged it to master
Gary Lumsden
@gjlumsden
Feb 02 2015 14:36
Quick question if anyone can help. Is the WWW-Authenticate header value only returned once - after the first failed request?
Brock Allen
@brockallen
Feb 02 2015 15:05
that's part of HTTP -- it's how the server challenges the user agent when a 401 is returned
Gary Lumsden
@gjlumsden
Feb 02 2015 15:06
That makes sense, but it doesn't return if a second request is issued and also fails for the same reason? This could be postman fiddling with the headers after the first one, but I expected a challenge each time.
Manuel Rauber
@ManuelRauber
Feb 02 2015 15:07
@henrikbiemann yes, as Brock said, it will take some time to finalize the merging and bringing it back to work. :-)
henrikniemann
@henrikniemann
Feb 02 2015 15:10
@ManuelRauber Cool, thanks. So the goal is to have client ui in admin?
Manuel Rauber
@ManuelRauber
Feb 02 2015 15:11
Yes. It will be the default when enabling the admin api
Brock Allen
@brockallen
Feb 02 2015 15:12
postman is not a good tool when is comes to accurately modeling security
it doesn't do cors correctly either
@henrikniemann yes -- like IdentityManager. self-contained, one assembly that embeds the assets
henrikniemann
@henrikniemann
Feb 02 2015 15:14
@brockallen @ManuelRauber Good stuff! Thanks.
Gary Lumsden
@gjlumsden
Feb 02 2015 15:14
@brockallen Tell me about it! Any recommendation for a replacement? I'll test with a dummy application for the time being and see if I can replicate this behaviour.
Brock Allen
@brockallen
Feb 02 2015 15:15
use real JS
John Korsnes
@johnkors
Feb 02 2015 15:15
fiddler?
Brock Allen
@brockallen
Feb 02 2015 15:15
we have several samples in the samples repo -- also a new simple JS client app was added. it gets access tokens wiht no helper libraries, and with as simple pure JS as possible
well, fiddler also doesn't do cors, but for just access tokens it's fine
Gary Lumsden
@gjlumsden
Feb 02 2015 15:16
Ok, I'll do that. Thanks.
Richard Bennett
@dealproc
Feb 02 2015 16:42
Richard Bennett
@dealproc
Feb 02 2015 17:22
Was there a design decision that caused scopes in IdSrv v3 to be global vs. in AuthSrv, you created scopes at the client level?
can somebody with experience with Identity framework help me a bit with general info on how to implement fine grained security inside app, please?
Richard Bennett
@dealproc
Feb 02 2015 18:44
That's application specific @FrenkR ... you use your bearer to identify your user, then build out whatever you need for your app.
how fine grained do you want to go?
FrenkR
@FrenkR
Feb 02 2015 18:45
FB stype
style
for each form each user can have different access priviliges
general question is what is a part of identityserver and what is a part of application
I am worried about access token size on each call to webapi
idea of client asking identity server for access token before each call to webapi is AFAIK too big overhead to me
Dominick Baier
@leastprivilege
Feb 02 2015 18:51
The access token only holds identity and coarse grained security information about user and client. This is used to map to permissions and authz policy.
In the web Api itself
Use eg custom authz attributes or our resource authz manager
Brian Donahue
@briandonahue
Feb 02 2015 20:46
I see a lot of calls “Checking subject is active” in my logs. Trying to understand why. Is that something only a client would initiate? I was under the impression that the OWIN OIDC MW wouldn’t do that, but maybe it is another client I don’t have direct control over, or is it idsrv itself for any reason?
Brock Allen
@brockallen
Feb 02 2015 20:53
Because you're using the access token validation endpoint in IdSvr, which checks to see if an access token is still valid, which then checks if the user is still active via the user service IsActive.
you can cache the validation results by setting the cache properties on the "use idsvr bearer" middleware options
Brian Donahue
@briandonahue
Feb 02 2015 20:54
ok, thanks - will look into that!
John Korsnes
@johnkors
Feb 02 2015 20:55
or do local validation (not use the token validation endpoint at all)
Brian Donahue
@briandonahue
Feb 02 2015 20:56
One of our auth sources is LDAP, and I was naively calling back to make sure there LDAP account still existed in this call :-o
Brock Allen
@brockallen
Feb 02 2015 21:24
right -- i think local autheN on the token is another thought. we should have docs on those... lemme look
hmm, doesn't look like we have docs for that middleware.
Brian Donahue
@briandonahue
Feb 02 2015 21:47
this is a different MW than the OIDC MW? I don’t really understand
I only have two types of clients currently, existing MVC apps using OWIN OIDC MW (implicit), and a Drupal client using code flow in a drupal plugin
not currently (at least intentionally) using access/bearer tokens, but looking into it for various APIs
John Korsnes
@johnkors
Feb 02 2015 22:04
if this is what they mean by validation, i guess you can rule out drupal..
brock was talking about the middleware validating bearer tokens in your APIs, btw. it's default mode is to validate by the token validation endpoint (for each request to your API)
Brock Allen
@brockallen
Feb 02 2015 22:07
oh yea, @briandonahue, that's what i thought you were talking about. if you're getting IsActive calls for OIDC authentication, then that's important -- you want to ensure the user is still legit each time they try to login somewhere (beyond the initial login page)
if your LDAP call is expensive, then maybe cache the result for an hour or so -- trade off between checking each time and performance
Brian Donahue
@briandonahue
Feb 02 2015 22:08
Oh… I thought that using Cookies Auth like the example, once I set my auth cookie at the client, it wouldn’t check with idsrv until that cookie expired?
definitely considering caching LDAP, but that is just one part of the problem, I am still trying to debug (amidst many distractions) why users are repeatedly making round trips to idsrv while navigating the app
Brock Allen
@brockallen
Feb 02 2015 22:09
right -- IsActive when you're just doing authentication is only called when the user's logging into IdSvr. if the user gets sent back to IdSvr to login again, even tho they're already logged in we still check IsActive
Brian Donahue
@briandonahue
Feb 02 2015 22:11
so only on round trip it should happen - not after authenticated/local cookie is set. (which would be explained that it is occuring because we are seeing round trips we don’t want happening)
Brock Allen
@brockallen
Feb 02 2015 22:13
right -- only when you've redirected the user to idsvr will it need to validate the user (and check IsActive)
Brian Donahue
@briandonahue
Feb 02 2015 22:14
ok, that’s what I thought, so it’s still the other issue
Brock Allen
@brockallen
Feb 02 2015 22:14
but it's also done from an web API that checks to see if an access token is still valid, but maybe you're not using access tokens
Brian Donahue
@briandonahue
Feb 02 2015 22:14
(random redirects)
has to be your API then, I guess
Brock Allen
@brockallen
Feb 02 2015 22:19
so yea, i don't know why your client app is redirecting back to idsvr -- only guess is that those calls aren't authenticated
are you also getting access tokens for APIs?