Hi Dilan, [1] How are we planning to get an OOT for each serial and in-case of an unenrollment, what is the process of getting a new OOT? Enrollment in this kind of a scenario, will only be done by a specific user in a role, and those users only. If unenrolled, the device must be handed to the people who can enroll for example a technician.
[2] Here, are plainning to do an enrollment without associating a user? if not, how will be other management functionalities carried out upon post-enrollment? User is needed currently since we are getting token in password grant type. In this scenario, as explained earlier, tokens will be created with a custom grant handler with the user of serial number and the OTT. Therefore we do not need to have a user. Regards, Inosh On Mon, Feb 1, 2016 at 5:00 PM, Dilan Udara Ariyaratne <[email protected]> wrote: > Hi Inosh, > > Please find my questions regarding this process as follows. > > [1] How are we planning to get an OOT for each serial and in-case of an > unenrollment, what is the process of getting a new OOT? > [2] Here, are plainning to do an enrollment without associating a user? if > not, how will be other management functionalities carried out upon > post-enrollment? > > Thanks. > > > > *Dilan U. Ariyaratne* > Software Engineer > WSO2 Inc. <http://wso2.com/> > Mobile: +94725197942 > lean . enterprise . middleware > > On Mon, Feb 1, 2016 at 3:49 PM, Inosh Perera <[email protected]> wrote: > >> Hi Harshan/Chathura, >> >> @Harshan - As Ayyoob mentioned, we can use a custom grant type >> handler for retrieving tokens. >> @Chathura - The technician will login to the command line tool and carry >> out operations, this avoids the need to type credentials to the device each >> time we need to enroll. >> Since after more analysis, we realized, that even in this method, there >> can be issues such as the time it takes to install drivers when connecting >> a device to the PC/ driver unavailability that can be an issue. Therefore, >> I have simplified the architecture as bellow. >> >> >> >> >> Regards, >> Inosh >> >> >> On Fri, Jan 29, 2016 at 12:41 AM, Ayyoob Hamza <[email protected]> wrote: >> >>> Hi Harshan >>> >>>> >>>> In the step 11, you have mentioned that the device sends authentication >>>> request, generate access and refresh tokens and send it to device. However >>>> you need client credentials (client key, secret) in-order to generate >>>> access tokens. How are you planing to get these client credentials prior to >>>> generating access tokens? In the existing EMM implementation we use >>>> Dynamic-client-registration to do that. I think we can use the same here. >>>> However we need to modify the flow diagram to reflect that. >>>> >>> >>> For bulk installation use case how about creating a custom grant type >>> handler which takes the OTT and validate and then provide an access token >>> as a response. Therefore in current flow we can replace the password grant >>> type handler with a custom grant type handler. >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Inosh Perera >> Software Engineer, WSO2 Inc. >> Tel: 077813 7285, 0785293686 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Inosh Perera Software Engineer, WSO2 Inc. Tel: 077813 7285, 0785293686
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
