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+ > 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 >> >> > -- -- Lahiru Sandaruwan WSO2 Inc., http://wso2.com lean.enterprise.middleware m: +1 901 530 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
