These are chat archives for IdentityServer/Thinktecture.IdentityServer3

6th
Mar 2015
Brock Allen
@brockallen
Mar 06 2015 13:45
@aaronpowell no -- still working on what shape it will take
too many irons in the fire, to be honest
but feel free to gran it as-is. at some point it will get turned into something formal. not sure if we will break it up into OidcClient and OidcTokenManager... i'm leaning that way
feedback welcome :)
Brandt Wright
@BrandtWright
Mar 06 2015 14:54
Is anyone familiar with any articles/samples/recommendations/best practices for implementing IDM/IDS in scenarios with two user stores (e.g. AD for B2B and LDS for B2C)?
Brock Allen
@brockallen
Mar 06 2015 16:02
question is do you want the uid/pwd login screen to check both stores, or do you want the user to somehow indicate which of those two they're from?
iow, for those 2 other stores, you could always make them external identity providers to the central IdSvr
H.İlter AKSENCER
@iltera
Mar 06 2015 16:55
Hi @brockallen,
I am working on a SPA with oidc.js
I am wondering, if it's somehow possible to access the "TokenManager.token" key in localstorage by a given function in oidc.js file.
Brock Allen
@brockallen
Mar 06 2015 16:57
the TokenMgr has an access_token property -- is that what you mean?
H.İlter AKSENCER
@iltera
Mar 06 2015 16:58
I think not, but wanted to double check before injecting localstorage in the interceptor (AngularJS)
The thing is,
Brock Allen
@brockallen
Mar 06 2015 16:58
actually, pretty much all the properties on the token "class" are exposed on the TokenManager
H.İlter AKSENCER
@iltera
Mar 06 2015 16:58
I don't want to send a request to the server for every page refresh
Brock Allen
@brockallen
Mar 06 2015 16:58
right
H.İlter AKSENCER
@iltera
Mar 06 2015 16:59
In the iodc example, everytime page refreshes, a new access_token is issued from the server
I want to check the access_token's expired property in order to prevent that.
Without sending a request to the server, I mean.
If it's expired, then I can go and ask to the server. For that, I need to access to the localstorage.
What is you recommendation?
Brock Allen
@brockallen
Mar 06 2015 17:00
i don't follow... the token is stored in local storage and it's just "there" on the token manager if the access token has not yet expired.
H.İlter AKSENCER
@iltera
Mar 06 2015 17:01
Even if someone refreshes the page?
Right...
Sorry,
Brock Allen
@brockallen
Mar 06 2015 17:01
correct. not sure why you had the impression it always went back to id svr
H.İlter AKSENCER
@iltera
Mar 06 2015 17:01
Let me explain again :) It's the end of the day and my head hurts a little :)
Brock Allen
@brockallen
Mar 06 2015 17:02
maybe the persist flag is disabled in that sample? there is a flag to disable the local storage behavior
but, IIRC, it defaults to true
H.İlter AKSENCER
@iltera
Mar 06 2015 17:02
No, no... My problem is not with that
give me a sec, I will explain.
Brock Allen
@brockallen
Mar 06 2015 17:02
ok
H.İlter AKSENCER
@iltera
Mar 06 2015 17:09

When you load the application, TokenMgr needs a configuration (that is config in the sample app). In order to get the mgr filled, I need to redirectForToken(), right? That makes the call to the server. And we get the access_token, id_token and everything we need. But if we refresh the page, providing that I have the TokenMgr in an interceptor class, that proccess repeats everytime when we have a refresh, or redirected to some other url and come back, etc.

I would like to check the localstorage value of the token's expired property before these all, and if I have a valid one, use that instead of going to the server and ask for a new token everytime.

I hope that's more clear this time :)
I can of course do that by using Angular's localstorage. But I wanted to double check if that feature exists within the oidc.js file somewhere.
Brock Allen
@brockallen
Mar 06 2015 17:15
in the ctor for the TokenMgr it tries to load from local storage, and so if the token is there then it's good to go (assuming it's not expired). if there's nothing in local storage or it's expired, then you woul[d need to redirectForToken(), yes.
so as soon as you create the token manager, you should be able to check the expired flag
H.İlter AKSENCER
@iltera
Mar 06 2015 17:16
Hımm... I assumed that it makes a call to the server. That makes sense now. Sorry :S
One more question
I would like to use the manager to get the id_token_hint, for logout controller.
How can I easyly reference the mgr without creating a config in the controller?
Brock Allen
@brockallen
Mar 06 2015 17:17
yea, that's a feature i need to add -- something to not keep the hint
H.İlter AKSENCER
@iltera
Mar 06 2015 17:18
Then I will put a TODO for that and move on, if you're planning on integrating it soon. Are planning on adding that feature soon? :)
Brock Allen
@brockallen
Mar 06 2015 17:22
not sure, but i'm working on that area now... so perhaps soon-ish
H.İlter AKSENCER
@iltera
Mar 06 2015 17:24
Thanks for the quick answers. Will be looking forward to it.
Brandt Wright
@BrandtWright
Mar 06 2015 17:39
@brockallen Ideally, I would like the uid/pwd screen to check both stores. Corporate users would be authenticated by AD. "Joe Internet" would be authenticated by LDS. And ids/idm would tack on whatever claims were relevant to that user.
Brandt Wright
@BrandtWright
Mar 06 2015 17:45
I am sure there are plenty of use cases for such a scenario (B2B + B2C). I just haven't seen any discussion around best practices for such a scenario. I am confident that I can implement the appropriate interfaces and wire everything up to get the job done. I was just hoping that there was something out there that could potentially save me some time. Not looking to reinvent the wheel and this seems like a fairly common ask. Then again, you made it extensible for a reason. Maybe I am asking for something that was intended to be implemented for each use case.
H.İlter AKSENCER
@iltera
Mar 06 2015 17:53
@brockallen I managed to solve my id_token_hint issue by injecting $rootScope in the interceptor and assigning the mgr.id_token to a $rootScope.id_token variable. Then used the $rootScope.id_token in the LogoutController. Logout is redirecting fine now. Thanks again ;)
Brock Allen
@brockallen
Mar 06 2015 17:56
@iltera wait... so the logout on the token manager was not sending the id token hint to the logout endpoint? it should be...
H.İlter AKSENCER
@iltera
Mar 06 2015 17:58
OidcClient.prototype.redirectForLogout = function (id_token_hint) { .... }
it takes a id_token_hint parameter. I didn't understand what you mean.
I just needed to pass that parameter for the logout function, and solved that with rootScope. Was there an easy way, I am missing?
Brock Allen
@brockallen
Mar 06 2015 17:59
right -- the token manager's redirectForLogout should have been passing it into that call
H.İlter AKSENCER
@iltera
Mar 06 2015 17:59
So, we're on the same page? :)
Brock Allen
@brockallen
Mar 06 2015 17:59
no clue :)
i wasn't following why you needed to get at it -- the token manager should have been doing it for you
H.İlter AKSENCER
@iltera
Mar 06 2015 18:00
"the token manager should have been doing it for you"
Can you clearify that?
Brock Allen
@brockallen
Mar 06 2015 18:00
there's an API on the TokenManager called redirectForLogout
H.İlter AKSENCER
@iltera
Mar 06 2015 18:00
You mean, it should have been a parameterless function?
Hımm... Just saw that.
Brock Allen
@brockallen
Mar 06 2015 18:01
if you're using the TokenManager and you call redirectForLogout, then it should be calling into the OidcClient's redirectForLogout and it will pass the id token hint automatically
H.İlter AKSENCER
@iltera
Mar 06 2015 18:06
Hahahah :D That's sooo funny!
I dived so deep in the subject that I missed the real simple one :D
I should have looked back at the sample project again...
Thank you, once again ;)
Brock Allen
@brockallen
Mar 06 2015 18:14
np