IdP always issues claims from its own dialect. If we want application specific claims - that is a functionality of the resource STS.
Thanks & regards, -Prabath On Mon, Nov 11, 2013 at 5:29 PM, Asela Pathberiya <[email protected]> wrote: > > > > On Mon, Nov 11, 2013 at 4:18 PM, Prabath Siriwardena <[email protected]>wrote: > >> Hi Asela, >> >> Yes.. I can remember we implemented something similar to applications - >> then again - I guess its a workaround.. >> >> Claim dialect is more specific to the protocol.. We have one dialect for >> SCIM , one for OpenID - and one for InfoCard likewise.. >> >> If an Application wants to add a user to the user store through SCIM API >> - it will use the SCIM dialect.. >> >> And also if an application wants add a user to the user store through >> Carbon API - it will use Carbon dialect. >> >> So - in my view Dialect is not Application specific - please correct me >> if not... >> > > Yes. I guess... Dialect may not be application specific. However i just > reminded one scenario that was implemented (just a demo). Two different > application use to control user self registration (addUsers) and user > profile viewing (getUser) using claim management. In that case, i > remembered that we used two claim dialect for these applications. Basically > application passes its claim dialect uri to retrieve claim data specific to > it. Also there can be some other cases (ex-asking SAML token using > WS-Trust) where we need to retrieve set of user attributes that is required > for an application. We can pack these set of attributes to one dialect > using claims. However, It seems to be that idea on dialect is specific to > the protocol... > > Thanks, > Asela. > > >> >> Thanks & regards, >> -Prabath >> >> >> On Mon, Nov 11, 2013 at 2:05 PM, Asela Pathberiya <[email protected]> wrote: >> >>> Hi Prabath, >>> >>> +1 for "Application" approach. This is one thing that we need to >>> implemented with WSO2 Identity Server. There are scenario where we have >>> already brought application concept by writing custom extension and so on. >>> Also i would like to add one more thing. I am not sure whether it is >>> overlap with the things that you have mentioned. >>> >>> -* Claim Dialect * >>> >>> Applications can maintain their own claim dialect in WSO2 Identity >>> Server. Different applications are retrieving user attribute using >>> different claim uri. As I understood, Claim uri is an application specific >>> thing. Default dialect would be used by "Carbon" application. >>> >>> Thanks, >>> Asela. >>> >>> >>> On Sun, Nov 10, 2013 at 10:56 PM, Prabath Siriwardena >>> <[email protected]>wrote: >>> >>>> 1. What is an Application under the context of Identity Server ? >>>> >>>> Its a consumer of identity attributes, roles (and groups), >>>> authentication methods/ policies and authorization policies. In practice, >>>> this could be a web application,mobile application - or even a desktop >>>> application. >>>> >>>> *- Identity attributes* >>>> >>>> A given user can be allowed to maintain his own set of attributes >>>> against different registered Applications. (multiple profiles) >>>> >>>> *- Permission / Roles* >>>> >>>> A given Application can maintain its own set of permissions with the >>>> Identity Server. That is, a given application can maintain its own set of >>>> resources and actions. For IS - Carbon is just another application - and >>>> its permissions / roles will be maintained as it is today. >>>> >>>> *- Authentication Policies.* >>>> >>>> A given Application can have its own set of trusted SAML2 IdPs + SAML >>>> response requirements(what attributes should be there, signed or not). It's >>>> own OAuth client key/secret. Its own WS-trust/STS policies. Also it can >>>> have its own user store. >>>> >>>> *- Authorization* *Policies* >>>> >>>> This is how we relate available permissions for an Application, to its >>>> roles. This can be finally represented in XACML. >>>> >>>> 2. How does this relate to multi-tenancy ? >>>> >>>> A given tenant can have its own set of Applications. >>>> >>>> 3. How does this work with Carbon ? >>>> >>>> Carbon it self is just another registered Application. >>>> >>>> 4. Don't we already have the Application concept in IS ? >>>> >>>> Yes.. we do.. but that is scattered across. In OAuth - we uniquely >>>> identify an application from the client key. When define a SAML2 Service >>>> Provider - we identify it by the EntityId. We don't have such concept for >>>> roles, permission, authorization policies. Idea is to unify this across the >>>> platform. >>>> >>>> The unique identifier of an application would be the client key. And >>>> for the administrative operations we need to provider an API - which is >>>> protected with OAuth. >>>> >>>> 5. Would this change the Identity Server Management Console UI ? >>>> >>>> Yes. We need to have a tab for defining and listing Applications. Also >>>> other tabs also need to absorb the Application concept while grouping. >>>> >>>> 6. How does this differ from the Application we create in API Manager ? >>>> >>>> It's the same + more capabilities. >>>> >>>> 7. How does this relate to Web Applications we host in Application >>>> Server ? >>>> >>>> Its the same. You define QoS parameters for those applications from >>>> this. >>>> >>>> Ideas, thoughts, questions mostly welcome... >>>> >>>> Thanks & Regards, >>>> Prabath >>>> >>>> Mobile : +94 71 809 6732 >>>> >>>> http://blog.facilelogin.com >>>> http://RampartFAQ.com >>>> >>> >>> >>> >>> -- >>> Thanks & Regards, >>> Asela >>> >>> ATL >>> Mobile : +94 777 625 933 >>> >> >> >> >> -- >> Thanks & Regards, >> Prabath >> >> Mobile : +94 71 809 6732 >> >> http://blog.facilelogin.com >> http://RampartFAQ.com >> > > > > -- > Thanks & Regards, > Asela > > ATL > Mobile : +94 777 625 933 > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
