Hi Lahiru,
It's available
in
WUM updated IS 5.3.0 pack
as well
. But for 5.3.0 you'll have to configure "spTokenExpireTime"
in
/_system/config/identity/config/spTokenExpireTime
by adding consumerkey of the application and the expiration times as a key
value pair in properties. Expiration times should be
in the format of
{
"userAccessTokenExpireTime" : 500000,
"applicationAccessTokenExpireTime" : 500000,
"refreshTokenExpireTime" : 500000
}
Thanks,
Rajith
On Wed, Feb 28, 2018 at 12:27 AM, Lahiru Sandaruwan <[email protected]>
wrote:
> Thanks Harsha. It seems it is available form IS 5.4.0.
>
>
> On Tue, Feb 27, 2018 at 11:58 AM, Harsha Thirimanna <[email protected]>
> wrote:
>
>>
>>
>> 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+Auth
>> entication+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
>>>
>>>
>>
>
>
> --
> --
>
> 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
>
>
--
*Rajith Siriwardana*
WSO2 Inc. | http://wso2.com
*lean. enterprise. middleware*
---------------------------------------------------
*https://home.apache.org/~siriwardana
<https://home.apache.org/~siriwardana>*
Disclaimer: This communication may contain privileged or other confidential
information and is intended exclusively for the addressee/s. If you are not
the intended recipient/s, or believe that you may have received this
communication in error, please reply to the sender indicating that fact and
delete the copy you received and in addition, you should not print, copy,
re-transmit, disseminate, or otherwise use the information contained in
this communication. Internet communications cannot be guaranteed to be
timely, secure, error or virus-free. The sender does not accept liability
for any errors or omissions.
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
