On Tue, Feb 27, 2018 at 11:07 PM, Lahiru Sandaruwan <[email protected]>
wrote:

> Hi Harsha,
>
> Did we add application level validity period requirement to Roadmap? Do we
> plan to implement this in near future?
>

Per service provider wise expire time set to the bellow tokens are already
there in the product.

User Access Token
Application Access Token
Refresh Token

https://docs.wso2.com/display/IS540/Configuring+Inbound+Authentication+for+a+Service+Provider
​

>
> Thanks.
>
> On Tue, Apr 25, 2017 at 12:48 AM, Sanjeewa Malalgoda <[email protected]>
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 8:46 AM, Harsha Thirimanna <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On 21 Apr 2017 3:35 p.m., "Asela Pathberiya" <[email protected]> wrote:
>>>
>>> Hi IS/APIM team,
>>>
>>> Is $subject in our roadmap ?
>>>
>>> We will add this to the roadmap.
>>>
>>> This seems to be a required features.  Different applications may need
>>> the different user token expiry time based on their security level.
>>>
>>>
>>>
>>>
>>> Yes, it seems the application should have this capability to do.
>>> But what is the real use case to have this per user ?
>>>
>> It depends lets think user know he is going to use this for shorter
>> period(from mobile app) then he can request with smaller time (lets say 5
>> mins). Then from token issuer logic we can check application level max
>> value and issue token with requested validity period if requested time is
>> below what they allow in application level. So this is not really user
>> level thing but optional parameter we send on demand when we generate
>> tokens. If token generation request allows to send optional parameters like
>> DCR we will be able to send requested_validity(if not sent default
>> application level validity time will apply).
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>> Just heard that; IOT server may has already requirement with that;  It
>>> is needed to define a token expiry level based on their device type.  Say;
>>>  some device's token may be embedded & these token may have longer expiry
>>> time (never expired).  Also;  some devices type need a  less expiry time
>>> based on their security policies.   It is not sure how we are handled this
>>> with APIM feature without $subject.   But;  this can be easily handled, if
>>> we can have such feature inbuilt.
>>>
>>> Thanks,
>>> Asela
>>>
>>>
>>> --
>>> Thanks & Regards,
>>> Asela
>>>
>>> ATL
>>> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>>>              +358 449 228 979
>>>
>>> http://soasecurity.org/
>>> http://xacmlinfo.org/
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <071%20306%208779>
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> --
>
> Lahiru Sandaruwan
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +1 901 530 2379 <(901)%20530-2379>
> e: [email protected] b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to