On Sat, Sep 16, 2017 at 1:37 PM, Farasath Ahamed <[email protected]> wrote:
> > > > > On Sat, Sep 16, 2017 at 1:21 PM, Johann Nallathamby <[email protected]> > wrote: > >> Tenant domain of the application should always be read from the resource >> path - i.e. URL. >> >> We can't read it from the user since we will have to support SaaS mode, >> which is to authenticate with a super tenant user and create the >> application in a tenant. >> > > > Can we really do this? Authenticate from super tenant credentials and > create an application in tenant? > > Our token endpoint derives the app's tenant domain from the tenantDomain > of the user who created the app[1]. The assumption behind is that we can > create apps across tenants. ie. A user from super tenant cannot go and > create an app in a tenant. > I didn't think much about the DCR use case. I was talking in general. First we need to think if SaaS scenario is applicable for DCR. If it is we need to fix above limitation :). AFAIK above limitation comes because of the limitation in the schema we have. And may be some model objects. Nothing else. This is because OAuth2 was written way before IS 5.0.0 which introduced SaaS concept. May be we even don't need to fix it immediately. But we must follow same security pattern for all Rest endpoints, regardless of limitations within the component. > > > [1] https://github.com/wso2-extensions/identity-inbound-auth > -oauth/blob/master/components/org.wso2.carbon.identity. > oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/A > ccessTokenIssuer.java#L129 > > >> >> Please note that this is a standard pattern we follow in IS now, for >> almost all endpoints. Therefore no one could be ignorant about it. Any new >> Rest endpoint development must follow the same security pattern. We do >> this with the help of the Authn/Authz valve implemented by Harsha. >> >> Regards, >> Johann. >> >> On Sat, Sep 16, 2017 at 1:11 PM, Hasintha Indrajee <[email protected]> >> wrote: >> >>> Just asking for my knowledge, >>> >>> How do we identify the tenant domain of the application ? Do we have it >>> in the context path ?, do we get it from user ?, or do we have anyway to >>> convey it within the body (by appending to something) ? In a case if we get >>> it from the identified user, how are we going to identify it from a request >>> without any authentication mechanism ?. >>> >>> On Sat, Sep 16, 2017 at 12:36 PM, Gayan Gunawardana <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Sep 15, 2017 at 2:47 PM, Hasini Witharana <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> In OIDC dynamic client registration, in the request header we need to >>>>> send an already existing user and the password to register a client in >>>>> WSO2 >>>>> Identity server.In OIDC specification[1], It is not mandatory to send user >>>>> details to register a client. >>>>> >>>>> When running the OIDC test suite for dynamic profile, test suite does >>>>> not send any user details in the header. So we can't create any client and >>>>> the test fails. >>>>> >>>>> For that issue if any user details are not provided in the >>>>> registration request we can assign an anonymous user(*wso2*. >>>>> *anonymous*.*user*) and register the client. >>>>> >>>> IMO correct design should be completely remove the requirement of >>>> having a user. If we use *"wso2*.*anonymous*.*user" *some application >>>> may have real username and some application may have *"wso2*. >>>> *anonymous*.*user" *which end up with inconsistency. >>>> Also need to think about creating a role per service provider if any >>>> user doesn't have that role. >>>> >>>>> >>>>> [1] - https://openid.net/specs/openid-connect-registration-1_0.html >>>>> >>>>> -- >>>>> >>>>> *Hasini Witharana* >>>>> Software Engineering Intern | WSO2 >>>>> >>>>> >>>>> *Email : [email protected] <[email protected]>* >>>>> >>>>> *Mobile : +94713850143 <+94%2071%20385%200143>[image: >>>>> http://wso2.com/signature] <http://wso2.com/signature>* >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "WSO2 Engineering Group" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Gayan Gunawardana >>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/ >>>> Email: [email protected] >>>> Mobile: +94 (71) 8020933 >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "WSO2 Engineering Group" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Hasintha Indrajee >>> WSO2, Inc. >>> Mobile:+94 771892453 <+94%2077%20189%202453> >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Senior Lead Solutions Engineer >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
