[JBoss JIRA] (ELY-1910) Develop JWT Token Issuer
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1910?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1910:
----------------------------
Fix Version/s: 2.0.0.Alpha7
(was: 2.0.0.Alpha6)
> Develop JWT Token Issuer
> ------------------------
>
> Key: ELY-1910
> URL: https://issues.jboss.org/browse/ELY-1910
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: API / SPI
> Reporter: Darran Lofthouse
> Priority: Major
> Fix For: 2.0.0.Alpha7
>
>
> Assigning to API / SPI for now but we may want to create a new component to track token based authentication, especially JWT.
> It may be desirable for us to be able to issue JWT tokens that can be used elsewhere.
> At the moment our identity propagation makes use of credentials delegated to us during authentication but we have some more opportunities if we can obtain new credentials dynamically for this propagation.
> An ideal use case for this could be a traditional web application already secured using traditional authentication such as username / password via a form, in that case the application will have a resulting SecurityIdentity with attributes, roles, and permissions assigned.
> This feature request is to consider a component internal to the process to convert the SecurityIdentity to a JWT token that can now be used for any outbound calls as the identity to propagate the identity.
> One possibility is some kind of transformation that can be applied on the SecurityDomain so the resulting SecurityIdentity has an associated JWT token credential as soon as it is created.
> Another alternative is more integration within authentication client, the destination could be taken into account so different tokens / mappings are applied for different destinations.
> I wont create the separate Jira issue yet but this could also open an option to dynamically obtain a token from a remote issuer - we may have been delegated a credential we can use to authentication against a remote identity provider and request a token that way.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (ELY-1888) Review Context Association
by Farah Juma (Jira)
[ https://issues.jboss.org/browse/ELY-1888?page=com.atlassian.jira.plugin.s... ]
Farah Juma updated ELY-1888:
----------------------------
Fix Version/s: 2.0.0.Alpha7
(was: 2.0.0.Alpha6)
> Review Context Association
> --------------------------
>
> Key: ELY-1888
> URL: https://issues.jboss.org/browse/ELY-1888
> Project: WildFly Elytron
> Issue Type: Task
> Components: API / SPI, MicroProfile
> Reporter: Darran Lofthouse
> Priority: Critical
> Fix For: 2.0.0.Alpha7
>
>
> Our APIs are very much written for objects to be associated with the current Thread and to remain associated either until they are replaced or the call stack returns to the point where association occurs and the association is automatically removed.
> Concurrent APIs are always a problem in this area as a "request" can now traverse multiple Threads, issues arise in relation to propagation to worker threads but also potentially in the association for any resulting callbacks / resumption of work across different threads.
> We should double check our relationship with Jakarta Concurrency: -
> https://projects.eclipse.org/projects/ee4j.cu
> The following specification within MicroProfile is looking into some mechanisms for this association: -
> https://github.com/eclipse/microprofile-context-propagation
> It may be preferable for our APIs to remain unchanged but instead we provide sufficient integration to capture our current context specific instances and propagate them.
> As we have more than one item that can be associated we may want to review if we want to use a single context internally that associates multiple items so we only have one item to propagate.
> Generally the items we associate are immutable so cross Thread modifications are not likely to be an issue.
> Alternatively we may choose to revisit our association APIs.
> Overall creating this issue for now as it is an area we will need to investigate further and plan for - tentatively scheduled against 2.0 although I suspect we will need to handle this within a 1.x release.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4677) [DMN Designer] Data Types - Handle read-only Data Types in the drag and drop list
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4677?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4677:
-------------------------------------------
[~dadossan] I believe that you are okay with the proposed mock, so I'm going to mark this as Resolved. And to follow-up on your point concerning indicating invalid drop targets - I found this guideline on the PF3 site:
??Hover over denied target: An icon should appear next to the cursor to signify an invalid drop target and the empty grey slot should remain at the original location where the item was selected.??
https://www.patternfly.org/v3/pattern-library/forms-and-controls/drag-and...
If there's anything else that's needed, please let me know and feel free to reopen the jira. Thanks.
[~karreiro] [~tirelli] ^^
> [DMN Designer] Data Types - Handle read-only Data Types in the drag and drop list
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-4677
> URL: https://issues.jboss.org/browse/DROOLS-4677
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.29.0.Final
> Reporter: karreiro
> Assignee: Elizabeth Clayton
> Priority: Major
> Labels: UXTeam, drools-tools, ux
> Attachments: Read-only.png
>
>
> The new drag and drop mechanism, added by the [Data Type UI enhancements|https://docs.google.com/presentation/u/1/d/10GZUd6oLaQohK27i...] does not specify how to handle read-only data types.
> Scenarios:
> - A User drags a regular data type to a position inside of read-only data type
> - A User drags a read-only data type to a position inside of regular data type
> _Notice: Read only data types appear when a DMN model has another DMN model included, and the external one has some data types._
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months