Hi all, On Tue, Nov 3, 2015 at 9:44 PM, Shakila Sivagnanarajah <[email protected]> wrote:
> We made following decisions in meeting. > > Before implementing the tiqr client in java, these should be done as > improvement. > > 1. Add tiqr authentication as another option like tiqr enrolment. > Are we going to add this option to authentication page, or should be done via editing profile, like we do in FIDO. > 2. Maintain tiqr User ID and IS username mapping in IS. > Is this a direct mapping between use and tiqr ID, or association between use and ID, What we do in facebook id association ? > > Thank you > > On Tue, Nov 3, 2015 at 10:36 AM, Shakila Sivagnanarajah <[email protected]> > wrote: > >> Hi Johann, >> >> We can track the IS user who logged in via tiqr, if we do this via >> two-factor authentication (we can do basic authentication as the first >> factor). And I don't think, saving these mapping detail in registry would >> be useful for future use. Because we have to use another User ID for next >> enrolment. If we keep this in registry, the number of records will increase >> in every attempt. >> >> Currently I'm using a third party Tiqr client (written in PHP) to get >> tiqr services and this component will act as a server (all tiqr side logics >> are written in this component). To access that client, we start that client >> on our local computer with an IP address (local IP address of the >> computer). And we use that IP as the host name to access tiqr services >> provided by that client. Now that client is separate thing and its IP >> depends on the network. Therefore we have to give that IP in the Identity >> Provider dashboard. The User will give the User ID and Display Name via UI >> (JSP page). >> >> My next step is implementing that tiqr client in java and we have to host >> that as a centralised one. After that, we don't need to specify the IP in >> Identity provider. >> >> We can discuss this further via hangout. >> >> Thank you >> >> On Tue, Nov 3, 2015 at 12:59 AM, Johann Nallathamby <[email protected]> >> wrote: >> >>> Hi Shakila, >>> >>> Enrolment is fine. However I think we need to have some kind of >>> reference to the enrolled user ID in tiqr to the username in IS. Otherwise >>> how are we going to relate/know the user who has actually logged in with >>> tiqr. All that tiqr might say is (this is what I am thinking, not yet >>> validated) that the login was successful for the provided user ID in tiqr. >>> But only if we can correlate that tiqr user ID to an IS username we can >>> take it as a second factor authentication for the particular IS user. >>> Otherwise what we only know is that the authentication was successful for >>> the tiqr user ID but don't know who the corresponding IS user is. >>> >>> As you say tiqr user IDs must be unique, and a single IS username can >>> have multiple tiqr user IDs. For that we need to maintain some kind of >>> mapping between the IS username, requesting site and tiqr user ID. >>> >>> Correct me if I am wrong. Anyway let's have a hangout to discuss this >>> further. >>> >>> Also regarding the diagram I think what you depict as Tiqr client is >>> also part of the authenticator. Right? What you don't have here is the tiqr >>> server component. Right ? >>> >>> And the first step says "User invoke the authenticator with User ID, >>> tiqr client IP and Display Name". I am not exactly sure who you mention by >>> user. If its the end user who is trying to login to IS, it is wrong to >>> expect that user to provide Tiqr client IP. He may only provide the tiqr >>> user ID and Display Name for enrolment. What the role of the tiqr client IP >>> here? And how is it used ? >>> >>> Let's have a hangout to discuss this further in detail >>> >>> Regards, >>> Johann. >>> >>> On Mon, Nov 2, 2015 at 10:26 PM, Shakila Sivagnanarajah < >>> [email protected]> wrote: >>> >>>> Hi Johann, >>>> >>>> There is another method called authentication available in tiqr. If we >>>> have an enrolled tiqr user in mobile device, we can use tiqr >>>> authentication. If we don't have any pre-enrolled user in mobile device, we >>>> can't use tiqr authentication. And we can't expect the user to have an >>>> pre-enrolled user on mobile device. Therefore I chose enrolment for this IS >>>> authenticator. And we are not going to store any account details (User ID >>>> and Display Name) in IS. Since we have to use unique User ID for each >>>> enrolment, we can't map the User ID with IS credentials (Username and >>>> Password). >>>> >>>> You can get the idea of tiqr IS authenticator from this diagram: >>>> >>>> [image: Inline image 1] >>>> >>>> Thank you >>>> >>>> On Mon, Nov 2, 2015 at 9:42 PM, Johann Nallathamby <[email protected]> >>>> wrote: >>>> >>>>> Hi Shakila, >>>>> >>>>> If you have already planned on how to achieve this, can you elaborate >>>>> a little more (ideally using a diagram) on how the end user experience is >>>>> going to be for enrolment and authentication flows once this authenticator >>>>> is completed ? What I want to know is at which point will the enrolment >>>>> process will happen and how the authentication experience looks like for >>>>> the end user. >>>>> >>>>> Also tiqr allows multiple user accounts to be created with a single >>>>> user device. Will some of these account details also be stored in IS? In >>>>> that case we need to decide where we will store all those accounts in IS >>>>> >>>>> Thanks. >>>>> >>>>> On Sun, Nov 1, 2015 at 12:09 PM, Shakila Sivagnanarajah < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I implemented an IS authenticator for Tiqr API. To authenticate a >>>>>> user via IS authenticator, I used user enrolment in tiqr. Since there is >>>>>> no >>>>>> cloud API to get tiqr functionalities, I used a PHP client to get tiqr >>>>>> on a >>>>>> local system. Now I am going to implement a java client to perform user >>>>>> enrolment in tiqr. Please find the milestone plan [1]. For more details >>>>>> on >>>>>> this API, refer [2] and [3]. >>>>>> >>>>>> [1] >>>>>> https://docs.google.com/a/wso2.com/spreadsheets/d/1tRL2uOm-j7VKSHIMaw8d-jzkEAY4nQU3XEf01YDIwyk/edit?usp=sharing >>>>>> >>>>>> [2] https://tiqr.org/ <https://tiqr.org/> >>>>>> >>>>>> [3] >>>>>> http://static.usenix.org/event/lisa11/tech/full_papers/Rijswijk.pdf >>>>>> >>>>>> >>>>>> Thank you >>>>>> -- >>>>>> Shakila Sivagnanarajah >>>>>> Associate Software Engineer >>>>>> Mobile :+94 (0) 770 760240 >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> >>>>> *Johann Dilantha Nallathamby* >>>>> Technical Lead & Product Lead of WSO2 Identity Server >>>>> Governance Technologies Team >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - *+94777776950* >>>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>>> >>>> >>>> >>>> >>>> -- >>>> Shakila Sivagnanarajah >>>> Associate Software Engineer >>>> Mobile :+94 (0) 770 760240 >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> >>> *Johann Dilantha Nallathamby* >>> Technical Lead & Product Lead of WSO2 Identity Server >>> Governance Technologies Team >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777776950* >>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>> >> >> >> >> -- >> Shakila Sivagnanarajah >> Associate Software Engineer >> Mobile :+94 (0) 770 760240 >> [email protected] >> > > > > -- > Shakila Sivagnanarajah > Associate Software Engineer > Mobile :+94 (0) 770 760240 > [email protected] > -- Ishara Karunarathna Senior Software Engineer WSO2 Inc. - lean . enterprise . middleware | wso2.com email: [email protected], blog: isharaaruna.blogspot.com, mobile: +94717996791
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
